Very nice.
Should have been done 30 years ago.
Simple Dynamic Strings library for C, compatible with null-terminated strings
71–80 of 85 posts
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#72Earlier quoted context omitted.
A shortcoming (or outright failure) of C is the lack of an extensive "batteries included" library. Maybe not C + Knuth, but some way of portably advancing the language over time.
Why? So we could be stuck with horrible interfaces forever (most of string.h comes to mind)? No thanks.
don't you think it could evolve?
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#73Earlier quoted context omitted.
A shortcoming (or outright failure) of C is the lack of an extensive "batteries included" library. Maybe not C + Knuth, but some way of portably advancing the language over time.
glib
That would be a start, but my though is more closely related to the C standard, not an add-on like boost.
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#74Earlier quoted context omitted.
An interesting - but not surprising - thing about this is that compression algorithms can be more efficient on wider representations of numerically-high code points (e.g, for some Korean corpus, using UTF-32 instead of UTF-8 improves LZMA compression by ~10%).
How well does that corpus compress with LZMA if using a Korean specific character code (such as EUC-KR)? And what about other combinations, with other character codings and other compression algorithms?
EUC-KR doesn't improve much with LZMA (2% over UTF-16), but is better with gzip-9 (10% over UTF-16). I haven't studied this extensively, just did a few tests when waiting for it to download.
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#75Hi, author here. May make sense to make SDS in perspective given a few comments I'm reading here. 1. Yep, more than "strings" SDS may be consider a library for dynamic buffers, especially from people coming from C++ or higher level languages. However I think that for C, it makes sense to provide a very low level thing like that. 2. In practice, if you see how SDS is used (extensively) inside Redis, it normally models…
Whenever I've used functionality like this before, the inevitable problem is the string ends up with nulls in it, meaning C and the library disagree on the length of the string, which inevitably causes problems and corruption. How do you handle this?
You use sdslen() instead of strlen(). Ditto for everything else. Failure to do so results in subtle bugs.
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#76Earlier quoted context omitted.
Whenever I've used functionality like this before, the inevitable problem is the string ends up with nulls in it, meaning C and the library disagree on the length of the string, which inevitably causes problems and corruption. How do you handle this?
You use sdslen() instead of strlen(). Ditto for everything else. Failure to do so results in subtle bugs.
Then why bother making these strings superficially compatible with C strings? Just printf or am I missing something?
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#77Earlier quoted context omitted.
How do you implement stack allocation support inside a C library function? How is de-allocation expressed?
alloca()?
No. Quoting the manual page:
The alloca() function allocates size bytes of space in the stack frame of the caller. This temporary space is automatically freed when the function that called alloca() returns to its caller.
That would not work, since the code calling alloca() is the library, and you want the to allocate on the stack frame of the function calling the library. I don't think that is possible, unless you make the library function into a macro (perhaps using ?: on the allocation size).
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#78Earlier quoted context omitted.
Whenever I've used functionality like this before, the inevitable problem is the string ends up with nulls in it, meaning C and the library disagree on the length of the string, which inevitably causes problems and corruption. How do you handle this?
You use sdslen() instead of strlen(). Ditto for everything else. Failure to do so results in subtle bugs.
Then (in my opinion) the library shouldn't advertise itself as compatible with Null terminated C strings, as users will assume that means they can use strlen (or more likely, other functions which use strlen themselves).
In a similar system I work on, we have a list of functions (like strlen, Strcat), where we carefully vet every occurrence in the code base. It's annoying but the only way to stop subtle bugs we've found.
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#79Earlier quoted context omitted.
I actually prefer the inline function here (while making the member char* private when compiling as C++), since that mostly prevents assignment to the member variable in settings where that would not be a valid operation. With that said, I agree that the additional verbosity is a significant drawback, and I can understand going with the slightly-less-safe option for that reason alone.
Ah, that’s a good point. I’m a fan of extra safety, though we’d need to make a few extra changes to get around C’s lack of private variables: We could make the internal member instead a size_t, and cast to pointer form when needed inside the library or when converting via this inline function (which is still a no-op in terms of performance). The only major downside then remaining is perhaps syntax/verbosity, which IM…
Good point about implicit conversions; I may actually be able to use that to clean up some code in the near future.
Re: Simple Dynamic Strings library for C, compatible with null-terminated strings
#80An unpopular opinion: just use the C++ as a better C and get firm static typechecking against this 'sds' type. And I personally would rather include const char* getUTF8StringPtr(sds) rather than an operator overload too.
When I have a major refactoring project, I typically will try to compile it with C++ first to help catch all the weird wobbly bits like this.
[EDIT: I now see in the comments other people with a similar opinion, so maybe not as unpopular as I would've thought!]