4 ms·

> Sure, you can't get away from handling the cases, but as the article clearly demonstrates, there can be a much better interface for it. It's a very apples to

> Sure, you can't get away from handling the cases, but as the article clearly demonstrates, there can be a much better interface for it. It's a very apples to oranges comparison, to the point that it almost feels like a straw man. "Interface (that does X) sucks for doing Y; look at how easy the Rust interface for doing Y is!" Yes, there can be a much simpler interface for the case when you want to assert that a string is nothing but digits and must fully convert. That's not what strtol is for though. Now I think libc sucks (no surprise given its age; complaining about is beating a dead horse), and it sucks more if you don't take various GNU & BSD extensions with it, but I'm kinda getting tired of people complaining that "foo in C is hard" when their unstated requirement is that they can't use any libraries to help them do it. Like this fellow the other day: https://news.ycombinator.com/item?id=29990897 https://news.ycombinator.com/item?id=29990897 If you look at programs written in "modern" languages, they almost invariably bring a plethora of libraries and dependencies with them anyway so why is C repeatedly judged on the merits of ancient libc interfaces that you don't have to use?

xigoi 5y ago
IMO, external libraries are for domain-specific tasks. If something is needed in pretty much every program, it should be a part of the language or the standard library. Also, it's much easier to use external libraries in other languages. npm install, cargo install, nimble install, cabal install, gem install, …
- foxfluff 5y ago
  > If something is needed in pretty much every program, it should be a part of the language or the standard library. It sure would be convenient that way. That said, you don't need to convert strings in pretty much every program. There's a lot of C code out there that does very little with strings. Now do you dismiss an entire language if its standard library is lacking or doesn't exist? IMO that would be throwing out baby with the bathwater. > npm install, cargo install, nimble install, cabal install, gem install, … Yes, I've witnessed the mountain of unaudited dependencies that somehow turn a 300 line program into something the size of my kernel.. should I dismiss all those languages because people do something I don't like with their libraries?
  - xigoi 5y ago
    I wonder how your programs do I/O if not with strings. Reading numbers from STDIN is the next thing after Hello World. As another comment pointed out, C has many flaws unrelated to its standard library. Also check out https://eev.ee/blog/2016/12/01/lets-stop-copying-c/ https://eev.ee/blog/2016/12/01/lets-stop-copying-c/. You know what's the main cause of dependency hell? Needing a library for every basic thing. Notice that mountains of dependencies are much less common in “batteries-included” languages.
    - foxfluff 5y ago
      > I wonder how your programs do I/O if not with strings. There's this one weird trick we call binary. Let me give you an example of how I did I/O yesterday: static void usb_tx(struct usb_ep *ep, const void *data, uint len) { if (len) memcpy(ep->buf, data, len); *ep->bufctl = BC_FULL | ep->datax << BC_DATAX_S | BC_AVAIL | len; ep->datax ^= 1; } Usage example: struct kb_report r = {.m={.id=KB_ID_M, .x=-a[1], .y=-a[0]}}; usb_tx(KB_IN, &r.m, sizeof r.m); stdin does not exist in this program. > As another comment pointed out, C has many flaws unrelated to its standard library. Yes it does, but this thread has already become a tangent of a tangent. Let's not turn it into a general diatribe against C, as opposed to a discussion about the library interface that TFA takes issue with. > You know what's the main cause of dependency hell? Needing a library for every basic thing. Notice that mountains of dependencies are much less common in “batteries-included” languages. In theory, yes. Like I said, libc sucks, and I would love to have a better standard (or de-facto standard) library. But anecdotally C programs are not very prone dependency bloat, perhaps precisely thanks to the fact that C doesn't have a de-facto package manager that allows you to just install a bunch of crap. Anecdotally, "batteries included" languages are still prone to dependency bloat if there's a package manager. This includes recent experience with Python (I can't remember the last time I had to lay my hands on a python project that didn't need a bunch of things to be installed with pip) and somewhat less recently with Perl (isn't cpan pretty much the grandfather of "oh there's a library for that"?). Hilariously, my recent experience has people using Python and depending on Python libraries which then depend on C and C++ libraries in order to implement the same things that I'm doing in plain C with no dependencies. But I'll conclude my participation in this subthread with this message because it's gone too far off the rails into a pointless language flame war.
lanstin 5y ago
I think my point remains valid, to do safe string stuff in C I have to think a lot harder about stuff to do with lengths that I don't have to think about in go. And I didn't want large dependencies because i was writing a .so to preload and intercept execve and open. And even after all these threads I don't know the name of a small string library to use in C, except TCL because i used it before.
- foxfluff 5y ago
  Would you be open to sharing what you did with strings? My central argument in the response there is that writing buf[len] = ‘\0’; is almost always a sign that you either don't know libc functions, aren't willing to use them, are trying to outperform them (the performance of libc functions is a legitimate complaint for some use cases), or what you're dealing with is not a string but some arbitrary binary blobs that you're trying to make strings out of (in that case, you can't blame the string representation or string handling functions for not knowing what the extent of your binary is; yes, you'll have to first create a string, knowing the length). To put it more explicitly, if you always provide a valid buffer and size, snprintf() will always terminate your string. strlcat() and strlcpy() will always terminate your string. If you need formatted catenation, you can make a trivial wrapper around snprintf that takes a pointer to the end of your string and updates the "head"; this can be called successively without ever having to compute a length outside the wrapper. asprintf() will allocate and terminate your string. Things that need the length of your string (strspn, strchr, etcetra) will figure it out since it is implied by the already-present nul byte. strtok & co (they have their issues) also work without requiring you to do any manual termination. What this means in practice is that you can have thousands of lines of string handling code that never manually terminates a string and only deals with lengths to the extent that your "business logic" needs to. Unless you're actually trying to use the string representation to your benefit by manually splicing it any which way, inserting nul bytes based on arcane computations.. in that case, it sounds like you got what you wanted. Yes, people actually do that sometimes: they figure out how easy it is to manipulate the string representation by hand and thus avoid library functions, and then they complain about doing it by hand. There are always exceptions of course, so I'm giving you benefit of the doubt. That's why I'm curious to see what you were doing. Having to point out library functions however is a regular thing as people seem to always start out by hand-rolling it for some reason. As for the question about string libraries.. well, I gotta point out that "small" wasn't a qualifier in the previous discussion. Popular libraries include sds, bstring, glib strings. Plan9port also has the extensible string library. There's icu for fancy unicode stuff but I have no experience with it and it probably isn't "small." There are plenty more if you look around, and I'll let you judge the size of the choices for yourself. I'm pretty sure one of these choices is always mentioned in these HN threads when someone asks for recommendations, including sds in the bchs thread.

xigoi 5y ago

IMO, external libraries are for domain-specific tasks. If something is needed in pretty much every program, it should be a part of the language or the standard library. Also, it's much easier to use external libraries in other languages. npm install, cargo install, nimble install, cabal install, gem install, …

foxfluff 5y ago
> If something is needed in pretty much every program, it should be a part of the language or the standard library. It sure would be convenient that way. That said, you don't need to convert strings in pretty much every program. There's a lot of C code out there that does very little with strings. Now do you dismiss an entire language if its standard library is lacking or doesn't exist? IMO that would be throwing out baby with the bathwater. > npm install, cargo install, nimble install, cabal install, gem install, … Yes, I've witnessed the mountain of unaudited dependencies that somehow turn a 300 line program into something the size of my kernel.. should I dismiss all those languages because people do something I don't like with their libraries?
- xigoi 5y ago
  I wonder how your programs do I/O if not with strings. Reading numbers from STDIN is the next thing after Hello World. As another comment pointed out, C has many flaws unrelated to its standard library. Also check out https://eev.ee/blog/2016/12/01/lets-stop-copying-c/ https://eev.ee/blog/2016/12/01/lets-stop-copying-c/. You know what's the main cause of dependency hell? Needing a library for every basic thing. Notice that mountains of dependencies are much less common in “batteries-included” languages.
  - foxfluff 5y ago
    > I wonder how your programs do I/O if not with strings. There's this one weird trick we call binary. Let me give you an example of how I did I/O yesterday: static void usb_tx(struct usb_ep *ep, const void *data, uint len) { if (len) memcpy(ep->buf, data, len); *ep->bufctl = BC_FULL | ep->datax << BC_DATAX_S | BC_AVAIL | len; ep->datax ^= 1; } Usage example: struct kb_report r = {.m={.id=KB_ID_M, .x=-a[1], .y=-a[0]}}; usb_tx(KB_IN, &r.m, sizeof r.m); stdin does not exist in this program. > As another comment pointed out, C has many flaws unrelated to its standard library. Yes it does, but this thread has already become a tangent of a tangent. Let's not turn it into a general diatribe against C, as opposed to a discussion about the library interface that TFA takes issue with. > You know what's the main cause of dependency hell? Needing a library for every basic thing. Notice that mountains of dependencies are much less common in “batteries-included” languages. In theory, yes. Like I said, libc sucks, and I would love to have a better standard (or de-facto standard) library. But anecdotally C programs are not very prone dependency bloat, perhaps precisely thanks to the fact that C doesn't have a de-facto package manager that allows you to just install a bunch of crap. Anecdotally, "batteries included" languages are still prone to dependency bloat if there's a package manager. This includes recent experience with Python (I can't remember the last time I had to lay my hands on a python project that didn't need a bunch of things to be installed with pip) and somewhat less recently with Perl (isn't cpan pretty much the grandfather of "oh there's a library for that"?). Hilariously, my recent experience has people using Python and depending on Python libraries which then depend on C and C++ libraries in order to implement the same things that I'm doing in plain C with no dependencies. But I'll conclude my participation in this subthread with this message because it's gone too far off the rails into a pointless language flame war.

lanstin 5y ago

I think my point remains valid, to do safe string stuff in C I have to think a lot harder about stuff to do with lengths that I don't have to think about in go. And I didn't want large dependencies because i was writing a .so to preload and intercept execve and open. And even after all these threads I don't know the name of a small string library to use in C, except TCL because i used it before.

foxfluff 5y ago
Would you be open to sharing what you did with strings? My central argument in the response there is that writing buf[len] = ‘\0’; is almost always a sign that you either don't know libc functions, aren't willing to use them, are trying to outperform them (the performance of libc functions is a legitimate complaint for some use cases), or what you're dealing with is not a string but some arbitrary binary blobs that you're trying to make strings out of (in that case, you can't blame the string representation or string handling functions for not knowing what the extent of your binary is; yes, you'll have to first create a string, knowing the length). To put it more explicitly, if you always provide a valid buffer and size, snprintf() will always terminate your string. strlcat() and strlcpy() will always terminate your string. If you need formatted catenation, you can make a trivial wrapper around snprintf that takes a pointer to the end of your string and updates the "head"; this can be called successively without ever having to compute a length outside the wrapper. asprintf() will allocate and terminate your string. Things that need the length of your string (strspn, strchr, etcetra) will figure it out since it is implied by the already-present nul byte. strtok & co (they have their issues) also work without requiring you to do any manual termination. What this means in practice is that you can have thousands of lines of string handling code that never manually terminates a string and only deals with lengths to the extent that your "business logic" needs to. Unless you're actually trying to use the string representation to your benefit by manually splicing it any which way, inserting nul bytes based on arcane computations.. in that case, it sounds like you got what you wanted. Yes, people actually do that sometimes: they figure out how easy it is to manipulate the string representation by hand and thus avoid library functions, and then they complain about doing it by hand. There are always exceptions of course, so I'm giving you benefit of the doubt. That's why I'm curious to see what you were doing. Having to point out library functions however is a regular thing as people seem to always start out by hand-rolling it for some reason. As for the question about string libraries.. well, I gotta point out that "small" wasn't a qualifier in the previous discussion. Popular libraries include sds, bstring, glib strings. Plan9port also has the extensible string library. There's icu for fancy unicode stuff but I have no experience with it and it probably isn't "small." There are plenty more if you look around, and I'll let you judge the size of the choices for yourself. I'm pretty sure one of these choices is always mentioned in these HN threads when someone asks for recommendations, including sds in the bchs thread.