7 ms·

Is there a good string-manipulation C library?

lanstin 5y ago
No? Asking for code nav and you get three answers. Asking for this and you get crickets. In the 90s I worked at a place where we embedded TCL into all the apps, and rolled our own templating systems. I had to do a little string stuff in C after few years of go, and it sucked. Ugg. buf[len] = ‘\0’; Using go, I thought I was getting back to low level stuff but this C experience made me appreciate strings in Go. Web servers in C are crazy bad idea, especially if they are spitting out html. Lisp would be better. Node would be better. Go would be better.
- foxfluff 5y ago
  > buf[len] = ‘\0’; So why didn't you use one of the bazillion library functions or third party libraries that terminate strings for you? I feel like most of the criticism is coming from people who punish themselves by rejecting library functions and then telling that strings are hard. Doh.
  - lanstin 5y ago
    I like to see the terminating nul in there, just in case my math was off earlier. I had strdup and so on. I was just way more work than go. And I was writing a LD_PRELOAD that I didn’t want to drag in any extra dependencies other than libc. Trust me, it is faster and safer and more fun in Go than C.
    - foxfluff 5y ago
      Alright, yea, if you're working under constraints like that, C sucks more than it has to. It just doesn't feel fair to criticize C without mentioning that your experience comes from working under such unusual constraints. "Strings are hard, C sucks" is quite different from "strings are hard, C sucks when you can't rely on libraries." Also feels unfair to say you get crickets when you ask for a lib but actually you weren't even willing to use one. (There are tons of string libraries for C, it's impossible to miss them if you look around.) Even then, if you're stuck working with only libc and your own code, there's a very high chance you're doing something wrong if you're doing math on strings and terminating them manually. There's a fair selection of libc functions that do all the math for you and will always output a properly terminated string if your inputs are a buffer & valid size and strings.
pjmlp 5y ago
Yes, SDS from Redis project. https://github.com/antirez/sds https://github.com/antirez/sds However the moment you call into other C libraries, they naturally only expect a char *.
- lelanthran 5y ago
  I got tired of running into this problem and decided to simply eat the cost of using `char *` in my string library.
  - pjmlp 5y ago
    And that is why most such efforts eventually die. WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that.
    - lelanthran 5y ago
      > WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that. Maybe it is, but even if it were, sds strings are a poor choice. I used them extensively in a private project. 1. Typedef'ing `sds` to a pointer type. This leaves no indication to the reader of code that any `sds` typed variable needs an `sdsfree`. IOW, for every other standard type it is clear when the data object needs a `free`, `fclose`, etc. This is a big deal, it's difficult to change the typedef for sds due to the way it returns pointers. 2. Not compatible with current string functions, strike 1: storing binary data in the strings, like the nul character makes it silently lose data when used with current string functions that accept `const char *`. This is a very big deal! 3. Not compatible with current string functions, strike 2: an sds string is only compatible with current string functions that take a `const char *`. This isn't such a big deal (for example, it provides a replacement for `strtok` as the standard `sds` type won't work for `strtok`) but it's unnecessarily incompatible. 4. With the current way it's exposed to a caller, you cannot use `const sds` variables anywhere, which removes a lot of compiler-checking. Trying to use `const` on any sds variable is pointless as you get none of the error-checking. While sds solves many problems with raw C strings, those problems can be solved by adding standard library functions that work with existing C strings. In addition, it adds a few more problems of its own.
lelanthran 5y ago
> Is there a good string-manipulation C library? You will have to define "good". My string library[1][2] is "good" for me because: 1. It's compatible with all the usual string functions (doesn't define a new type `string_t` or similar, uses existing `char *`). 2. It does what I want: a) Works on multiple strings so repeated operations are easy, and b) Allocates as necessary so that the caller only has to free, and not calculate how much memory is needed beforehand. The combination of the above means that many common string operations that I want to do in my programs are both easy to do and easy to visually inspect for correctness in the caller. Others will say that this is not good, because it still uses and exposes `char *`. [1] https://github.com/lelanthran/libds/blob/master/src/ds_str.h https://github.com/lelanthran/libds/blob/master/src/ds_str.h [2] Currently the only bug I know of is the quadratic runtime in many of the functions. I intend to fix this at some point.
avar 5y ago
The strbuf library that's part of git.git is a pleasure to work with. It's C-string compatible (just a char /size_t pair), guarantees that the "char " member is always NULL-delimited, but can also be used for binary data. It also guarantees that the "buf" member is never NULL: https://github.com/git/git/blob/v2.34.0/strbuf.h#L6-L70 https://github.com/git/git/blob/v2.34.0/strbuf.h#L6-L70
- MrBuddyCasino 5y ago
  This looks really well thought out - bookmarked.
pull_my_finger 5y ago
Can't vouch for any in particular, but they do exist. https://github.com/oz123/awesome-c#string-manipulation https://github.com/oz123/awesome-c#string-manipulation

No? Asking for code nav and you get three answers. Asking for this and you get crickets. In the 90s I worked at a place where we embedded TCL into all the apps, and rolled our own templating systems. I had to do a little string stuff in C after few years of go, and it sucked. Ugg. buf[len] = ‘\0’; Using go, I thought I was getting back to low level stuff but this C experience made me appreciate strings in Go. Web servers in C are crazy bad idea, especially if they are spitting out html. Lisp would be better. Node would be better. Go would be better.

foxfluff 5y ago
> buf[len] = ‘\0’; So why didn't you use one of the bazillion library functions or third party libraries that terminate strings for you? I feel like most of the criticism is coming from people who punish themselves by rejecting library functions and then telling that strings are hard. Doh.
- lanstin 5y ago
  I like to see the terminating nul in there, just in case my math was off earlier. I had strdup and so on. I was just way more work than go. And I was writing a LD_PRELOAD that I didn’t want to drag in any extra dependencies other than libc. Trust me, it is faster and safer and more fun in Go than C.
  - foxfluff 5y ago
    Alright, yea, if you're working under constraints like that, C sucks more than it has to. It just doesn't feel fair to criticize C without mentioning that your experience comes from working under such unusual constraints. "Strings are hard, C sucks" is quite different from "strings are hard, C sucks when you can't rely on libraries." Also feels unfair to say you get crickets when you ask for a lib but actually you weren't even willing to use one. (There are tons of string libraries for C, it's impossible to miss them if you look around.) Even then, if you're stuck working with only libc and your own code, there's a very high chance you're doing something wrong if you're doing math on strings and terminating them manually. There's a fair selection of libc functions that do all the math for you and will always output a properly terminated string if your inputs are a buffer & valid size and strings.

pjmlp 5y ago

Yes, SDS from Redis project. https://github.com/antirez/sds https://github.com/antirez/sds However the moment you call into other C libraries, they naturally only expect a char *.

lelanthran 5y ago
I got tired of running into this problem and decided to simply eat the cost of using `char *` in my string library.
- pjmlp 5y ago
  And that is why most such efforts eventually die. WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that.
  - lelanthran 5y ago
    > WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that. Maybe it is, but even if it were, sds strings are a poor choice. I used them extensively in a private project. 1. Typedef'ing `sds` to a pointer type. This leaves no indication to the reader of code that any `sds` typed variable needs an `sdsfree`. IOW, for every other standard type it is clear when the data object needs a `free`, `fclose`, etc. This is a big deal, it's difficult to change the typedef for sds due to the way it returns pointers. 2. Not compatible with current string functions, strike 1: storing binary data in the strings, like the nul character makes it silently lose data when used with current string functions that accept `const char *`. This is a very big deal! 3. Not compatible with current string functions, strike 2: an sds string is only compatible with current string functions that take a `const char *`. This isn't such a big deal (for example, it provides a replacement for `strtok` as the standard `sds` type won't work for `strtok`) but it's unnecessarily incompatible. 4. With the current way it's exposed to a caller, you cannot use `const sds` variables anywhere, which removes a lot of compiler-checking. Trying to use `const` on any sds variable is pointless as you get none of the error-checking. While sds solves many problems with raw C strings, those problems can be solved by adding standard library functions that work with existing C strings. In addition, it adds a few more problems of its own.

lelanthran 5y ago

> Is there a good string-manipulation C library? You will have to define "good". My string library[1][2] is "good" for me because: 1. It's compatible with all the usual string functions (doesn't define a new type `string_t` or similar, uses existing `char *`). 2. It does what I want: a) Works on multiple strings so repeated operations are easy, and b) Allocates as necessary so that the caller only has to free, and not calculate how much memory is needed beforehand. The combination of the above means that many common string operations that I want to do in my programs are both easy to do and easy to visually inspect for correctness in the caller. Others will say that this is not good, because it still uses and exposes `char *`. [1] https://github.com/lelanthran/libds/blob/master/src/ds_str.h https://github.com/lelanthran/libds/blob/master/src/ds_str.h [2] Currently the only bug I know of is the quadratic runtime in many of the functions. I intend to fix this at some point.

avar 5y ago

The strbuf library that's part of git.git is a pleasure to work with. It's C-string compatible (just a char /size_t pair), guarantees that the "char " member is always NULL-delimited, but can also be used for binary data. It also guarantees that the "buf" member is never NULL: https://github.com/git/git/blob/v2.34.0/strbuf.h#L6-L70 https://github.com/git/git/blob/v2.34.0/strbuf.h#L6-L70

MrBuddyCasino 5y ago
This looks really well thought out - bookmarked.

pull_my_finger 5y ago

Can't vouch for any in particular, but they do exist. https://github.com/oz123/awesome-c#string-manipulation https://github.com/oz123/awesome-c#string-manipulation