> marginal convenience(...) you won't get type warnings
The aliasing of char* permits the user to directly use all his string-read tools. I'm not super convinced myself it's the right design choice though but it sure is convenient.
The alternative would force him using Header->str every time he wants access to the real string.
Yes, there is no real type safety. The user has to be conscious. But he'll be warned by stx_t being const if he ever uses out-of-API writers.
> stx_load function is a bit out of place
I agree. It's a bit hard to know where to stop...
> not sold on the usefulness of having an append function that can't reallocate
For constrained/embedded environments ? Or just a socket buffer.
> I could emulate it with a reallocating version by just manually truncating the copy to the current capacity.
That would be much slower I think.
> Most C programmers would probably prefer to write their own instead
That's not good news haha
Why did you choose to use a char* typedef with a magic "header before" in the alloc, instead of just padding around the header struct? You get some marginal convenience when passing it into an api that expects a char, but it doesn't seem worth it when you consider that you won't get type warnings if you try to use a char where you expected an stx_t. (My understanding is that unlike C++, C compilers will generally allow wrong-pointer-types, but you can turn on warnings for it).
I think the stx_load function is a bit out of place, this doesn't seem like it should be a string library's responsibility. There is also the added issue that passing a char* in as a filepath is not suitable for windows. You (generally, there are other ways) need to use a wide char string on windows for file I/O, to handle non-ascii characters.
I'm also not sold on the usefulness of having an append function that can't reallocate. I have never wanted this, and if I did, I could emulate it with a reallocating version by just manually truncating the copy to the current capacity.
As for licensing commercially, I don't think that's likely to work out really. It is a useful project for sure, but I think it's just a bit too small to justify buying it. Most C programmers would probably prefer to write their own instead.