Re:Show HN: Stricks – managed C strings library
by alcover on Thursday March 25, 2021 @08:22PM
(#26587433)
Thank you
> 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
> 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