6 ms·

> the C std lib is the weakest part of the C language and it should only be used as a fallback. I've been musing for a while now: what would it look like if we

> the C std lib is the weakest part of the C language and it should only be used as a fallback. I've been musing for a while now: what would it look like if we were to discard the C library and design a new one, leaving the language itself intact?

stephc_int13 4y ago
I think it could be very nice. C is not perfect, there are some parts of the syntax that I strongly dislike, like casting or function pointers declaration... But it is overall a good enough syntax, much simpler than C++.
- marssaxman 4y ago
  Amending the syntax is fun but rapidly becomes a slippery slope; soon enough you find yourself designing a new successor language, as has been done many times before. Simply scrapping the mostly-unhelpful C stdlib and inventing new, modern abstractions for allocation, IO, text, threading, etc seems like a more tractable problem.
  - stephc_int13 4y ago
    I fully agree.
  - int_19h 4y ago
    It has the same fundamental problem, though: you have to rewrite most existing code, which hinders adoption. In this case, it might actually hinder it more than also improving the language itself, since people would be more willing to take that leap if there are more benefits to be had from it.
  - up2isomorphism 4y ago
    Stdlib is probably the most successful library in the history, not sure how it is “unhelpful”.
klodolph 4y ago
There are several libraries or projects where people have done exactly that. You often end up with some kind of structure, or variations of structures, for strings: struct string { size_t length; char data[]; }; struct string { size_t length; size_t alloc; char *data; }; Those are just examples. The tricky part is figuring out the different ownership use cases you want to solve. Because C gives you so much freedom and very little in the standard library, you end up with a lot of variations. You might use reference-counted strings, owned buffers, or string slices, etc. You might want certain types to be distinguished at compile-time and other types to be distinguished at run-time. An example can be found in the Git source code. https://github.com/git/git/blob/master/strbuf.h https://github.com/git/git/blob/master/strbuf.h The history of changes to this file is interesting as well. This is a relatively nice general-purpose string type—you can easily append to it or truncate it.
- stephc_int13 4y ago
  IMHO that does not solve the main problem, that is individual lifetime management. I've seen many libs using this style of strings, not convinced by the practicality.
  - nickff 4y ago
    What is "individual lifetime management"?
  - klodolph 4y ago
    It sounds like you’re rephrasing part of my comment back to me, or maybe I’m misinterpreting what you’re saying. If you’re not convinced of the practicality, it sounds like you are simply not convinced of the practicality of doing string processing in C at all, which is a fair view point. String processing in C is somewhat a minefield. Libraries like Git’s strbuf are very effective relative to other solutions in C, but lack safety relative to other languages.
    - stephc_int13 4y ago
oneshtein 4y ago
You can backport Rust standard library to C using https://github.com/eqrion/cbindgen https://github.com/eqrion/cbindgen .
athenot 4y ago
The old MacOS (pre-X) did just that. Strings were all "Pascal strings", ie. with the first byte containing the length of the actual string. Building blocks for memory were also very different from stdlib, notably the use of Handles, which were pointers of pointers, so that the OS could move a block of data around to defragment the heap behind your back without breaking the memory addressing.
- tialaramex 4y ago
  Pascal strings are also kind of bad though. All sub-string operations need allocation, or have to be defined with intermediate results which aren't "really" strings, so in that sense it's not an improvement on Zero-terminated strings. Equality tests are cheaper which is nice, since strings of different lengths compare unequal immediately, but most things aren't really improved. C++ string_view is closer to the Right Thing™ - a slice, but C++ doesn't (yet) define anywhere what the encoding is, so... that's not what it could be. Rust's str is a slice and it's defined as UTF-8 encoded.
  - WalterBright 4y ago
    D's strings were defined to be UTF-8 back in 2000. wstring is UTF-16, and dstring is UTF-32. Back then it wasn't clear which encoding method would turn out to be dominant, so we did all three. (Java was built on UTF-16.) As it eventually became clear, UTF-8 is da winnah, and the other formats are sideshows. Windows, which uses UTF-16, is handled by converting UTF-8 to -16 just before calling a Windows function, and converting anything coming back to UTF-8. D doesn't distinguish between a string and a string view.
    - saagarjha 4y ago
      What’s the ownership story for string views?
      - eco 4y ago
        They don't own anything. It's just a pointer and length. They don't allocate/deallocate.
epr 4y ago
The creator of this library (antirez) is a regular here on hn. I believe this is used by Redis. https://github.com/antirez/sds https://github.com/antirez/sds
WorldMaker 4y ago
Glib answer (but also relevant because mentioned in the article, too): it would look a lot like how a lot of people write C++.
- scythe 4y ago
  >Glib answer A Freudian slip, methinks.
  - WorldMaker 4y ago
    How so? First definition I find of glib is "(of words or the person speaking them) fluent and voluble but insincere and shallow", which is mostly what I meant about that answer. There was some sincerity in my answer, but certainly somewhere in the border space of irony and sarcasm, which many people do take as insincerity.
    - bingo3131 4y ago
      https://en.wikipedia.org/wiki/GLib https://en.wikipedia.org/wiki/GLib
  - deleted 4y ago
    [deleted]
scythe 4y ago
The problem is that it's just too tempting to write something like my_function(my_var, 3.6, "bzarflo", my_other_var, false); The string handling functions are part of the story, but the null-terminated char * is produced when the compiler reaches a string literal, and writing code without being allowed to just use string literals when it's convenient tends to feel like coding with oven mitts on.
- lolcatuser 4y ago
  It's entirely possible to write a wrapper function with a short name to convert string literals to actual string objects. my_function(my_var, 3.6, $("bzarflo"), my_other_var, false); Isn't that much more of a mouthful, and as long as 'my_function' knows to free it, then you're A-OK! The only trouble is '$()' isn't legal in standard C, so a real solution would have to be something like 'str()'.
rychco 4y ago
This caught my eye the other day & looks quite promising, though I haven't spent much time looking at it so I can't comment on it's memory safety: https://github.com/tylov/STC https://github.com/tylov/STC
quelsolaar 4y ago
I'm in the WG14 and my opinion is that there isn't one good way to do strings it all depends on what you value (performance/ memory use) and the usage pattern. C in general only deal with data types, north their semantic meaning. (IOW We say what a float is not what it is used for). The two main deviations from that are text and time and both of them are causing us a lot of issues. My opinion is that writing your own text code is the best solution and the most "C" solution. Te one proposal i have heard that i like is for C to get versions of functions that use strings that take an array and a length, so as to not force the convention of null termination in order to use things like fopen.
- hgs3 4y ago
  Has WG14 considered adding slices to C? [1] Introducing slices would naturally give way to a better string library. [1] https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html
  - quelsolaar 4y ago
    Its been 50 years so pretty much everything has been considered. In my opinion the mistake was not having arrays decay in to pointers but rather arrays should be pointers in the first place. An array should be seen as a number of values where with a pointer pointing at the first one. I think adding a third version of the same functionality would just complicate things further. (&p[42] is a "slice" of an array) Another thing I do not like about slices that store lengths, is that they hide memory layout from the user and that is not a very C thing to do.
    - uecker 4y ago
      If you think about arrays as pointers, you will get a lot of things wrong, e.g. float m[10][10]; it not a an array of pointers, but a 2D dimensional array with 2D memory layout.
      - quelsolaar 4y ago
tristan957 4y ago
GLib is an alternative to the standard library.

stephc_int13 4y ago

I think it could be very nice. C is not perfect, there are some parts of the syntax that I strongly dislike, like casting or function pointers declaration... But it is overall a good enough syntax, much simpler than C++.

marssaxman 4y ago
Amending the syntax is fun but rapidly becomes a slippery slope; soon enough you find yourself designing a new successor language, as has been done many times before. Simply scrapping the mostly-unhelpful C stdlib and inventing new, modern abstractions for allocation, IO, text, threading, etc seems like a more tractable problem.
- stephc_int13 4y ago
  I fully agree.
- int_19h 4y ago
  It has the same fundamental problem, though: you have to rewrite most existing code, which hinders adoption. In this case, it might actually hinder it more than also improving the language itself, since people would be more willing to take that leap if there are more benefits to be had from it.
- up2isomorphism 4y ago
  Stdlib is probably the most successful library in the history, not sure how it is “unhelpful”.

klodolph 4y ago

There are several libraries or projects where people have done exactly that. You often end up with some kind of structure, or variations of structures, for strings: struct string { size_t length; char data[]; }; struct string { size_t length; size_t alloc; char *data; }; Those are just examples. The tricky part is figuring out the different ownership use cases you want to solve. Because C gives you so much freedom and very little in the standard library, you end up with a lot of variations. You might use reference-counted strings, owned buffers, or string slices, etc. You might want certain types to be distinguished at compile-time and other types to be distinguished at run-time. An example can be found in the Git source code. https://github.com/git/git/blob/master/strbuf.h https://github.com/git/git/blob/master/strbuf.h The history of changes to this file is interesting as well. This is a relatively nice general-purpose string type—you can easily append to it or truncate it.

stephc_int13 4y ago
IMHO that does not solve the main problem, that is individual lifetime management. I've seen many libs using this style of strings, not convinced by the practicality.
- nickff 4y ago
  What is "individual lifetime management"?
- klodolph 4y ago
  It sounds like you’re rephrasing part of my comment back to me, or maybe I’m misinterpreting what you’re saying. If you’re not convinced of the practicality, it sounds like you are simply not convinced of the practicality of doing string processing in C at all, which is a fair view point. String processing in C is somewhat a minefield. Libraries like Git’s strbuf are very effective relative to other solutions in C, but lack safety relative to other languages.
  - stephc_int13 4y ago

oneshtein 4y ago

You can backport Rust standard library to C using https://github.com/eqrion/cbindgen https://github.com/eqrion/cbindgen .

athenot 4y ago

The old MacOS (pre-X) did just that. Strings were all "Pascal strings", ie. with the first byte containing the length of the actual string. Building blocks for memory were also very different from stdlib, notably the use of Handles, which were pointers of pointers, so that the OS could move a block of data around to defragment the heap behind your back without breaking the memory addressing.

tialaramex 4y ago
Pascal strings are also kind of bad though. All sub-string operations need allocation, or have to be defined with intermediate results which aren't "really" strings, so in that sense it's not an improvement on Zero-terminated strings. Equality tests are cheaper which is nice, since strings of different lengths compare unequal immediately, but most things aren't really improved. C++ string_view is closer to the Right Thing™ - a slice, but C++ doesn't (yet) define anywhere what the encoding is, so... that's not what it could be. Rust's str is a slice and it's defined as UTF-8 encoded.
- WalterBright 4y ago
  D's strings were defined to be UTF-8 back in 2000. wstring is UTF-16, and dstring is UTF-32. Back then it wasn't clear which encoding method would turn out to be dominant, so we did all three. (Java was built on UTF-16.) As it eventually became clear, UTF-8 is da winnah, and the other formats are sideshows. Windows, which uses UTF-16, is handled by converting UTF-8 to -16 just before calling a Windows function, and converting anything coming back to UTF-8. D doesn't distinguish between a string and a string view.
  - saagarjha 4y ago
    What’s the ownership story for string views?
    - eco 4y ago
      They don't own anything. It's just a pointer and length. They don't allocate/deallocate.

epr 4y ago

The creator of this library (antirez) is a regular here on hn. I believe this is used by Redis. https://github.com/antirez/sds https://github.com/antirez/sds

WorldMaker 4y ago

Glib answer (but also relevant because mentioned in the article, too): it would look a lot like how a lot of people write C++.

scythe 4y ago
>Glib answer A Freudian slip, methinks.
- WorldMaker 4y ago
  How so? First definition I find of glib is "(of words or the person speaking them) fluent and voluble but insincere and shallow", which is mostly what I meant about that answer. There was some sincerity in my answer, but certainly somewhere in the border space of irony and sarcasm, which many people do take as insincerity.
  - bingo3131 4y ago
    https://en.wikipedia.org/wiki/GLib https://en.wikipedia.org/wiki/GLib
- deleted 4y ago
  [deleted]

scythe 4y ago

The problem is that it's just too tempting to write something like my_function(my_var, 3.6, "bzarflo", my_other_var, false); The string handling functions are part of the story, but the null-terminated char * is produced when the compiler reaches a string literal, and writing code without being allowed to just use string literals when it's convenient tends to feel like coding with oven mitts on.

lolcatuser 4y ago
It's entirely possible to write a wrapper function with a short name to convert string literals to actual string objects. my_function(my_var, 3.6, $("bzarflo"), my_other_var, false); Isn't that much more of a mouthful, and as long as 'my_function' knows to free it, then you're A-OK! The only trouble is '$()' isn't legal in standard C, so a real solution would have to be something like 'str()'.

rychco 4y ago

This caught my eye the other day & looks quite promising, though I haven't spent much time looking at it so I can't comment on it's memory safety: https://github.com/tylov/STC https://github.com/tylov/STC

quelsolaar 4y ago

I'm in the WG14 and my opinion is that there isn't one good way to do strings it all depends on what you value (performance/ memory use) and the usage pattern. C in general only deal with data types, north their semantic meaning. (IOW We say what a float is not what it is used for). The two main deviations from that are text and time and both of them are causing us a lot of issues. My opinion is that writing your own text code is the best solution and the most "C" solution. Te one proposal i have heard that i like is for C to get versions of functions that use strings that take an array and a length, so as to not force the convention of null termination in order to use things like fopen.

hgs3 4y ago
Has WG14 considered adding slices to C? [1] Introducing slices would naturally give way to a better string library. [1] https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html
- quelsolaar 4y ago
  Its been 50 years so pretty much everything has been considered. In my opinion the mistake was not having arrays decay in to pointers but rather arrays should be pointers in the first place. An array should be seen as a number of values where with a pointer pointing at the first one. I think adding a third version of the same functionality would just complicate things further. (&p[42] is a "slice" of an array) Another thing I do not like about slices that store lengths, is that they hide memory layout from the user and that is not a very C thing to do.
  - uecker 4y ago
    If you think about arrays as pointers, you will get a lot of things wrong, e.g. float m[10][10]; it not a an array of pointers, but a 2D dimensional array with 2D memory layout.
    - quelsolaar 4y ago

tristan957 4y ago

GLib is an alternative to the standard library.