5 ms·

It would not be a small change if you wanted to actually make them usable for the standard library - ie. add a second 'struct bytes'-variant of EVERY function t

by dezgeg 4y ago

It would not be a small change if you wanted to actually make them usable for the standard library - ie. add a second 'struct bytes'-variant of EVERY function that currently accepts a NUL-terminated string. No, just calling a conversion function before (that would need heap allocation) would never be accepted by C programmers (for the overhead). Then there is inertia - how many really would want to port their application to a different string type? Not to mention, all the libraries you're using would also have to been converted.

pjmlp 4y ago
Inertia is no excuse, if something like SDS was adopted by WG14, eventually C applications could slowly be migrated into it. As it is, it will never happen.
- ranger_danger 4y ago
  SDS is cool, I use it in my projects and have also extended it further with some new features... but I worry about the amount of dynamic allocation going on, it would be nice to have an alternative solution such as using stack or pool allocations, or being able to declare SDS string literals at compile-time (probably only possible in C++). Every time I notice that I need to replace a const char* with an SDS I just know I'm slowing things down and adding more complexity.
  - pjmlp 4y ago
    It doesn't have to be 1:1 equal to SDS, rather at least having WG14 doing something, anything at all, instead of keeping pushing the agenda of C being a Swiss cheese of security exploits, to the point everyone is adopting hardware memory tagging as the ultimate mitigation.
matheusmoreira 4y ago
For some reason C seem to be going through standard updates as often as C++ now. Not only that, they've added absolutely huge stuff like threading primitives as well as an insane generic macro thing. Surely they could add better designed structures and functions for dealing with memory.
duped 4y ago
Copy C++. The underlying string buffer must be null terminated, but still carry its length.
wongarsu 4y ago
You can make the read-only conversion "free" by storing both the size of the string, as well as terminating the actual string contents with a NUL. So the String "bar" would be { length: 3, contents: ['b', 'a', 'r', '\0\] }. All your functions dealing with the "rich" string type work the same using the length, except they have to be aware of the need to preserve the terminating 0, and you if you want to pass a read-only string to a legacy function you can just pass it contents. Of course that also generates a giant foot gun because you might manage to get the old and new strlen to disagree on the size, because one reads the length field and the other searches the \0.
dralley 4y ago
Is that really so big a deal, considering they've done that multiple times already anyway? How many versions of strcpy, printf, and other string handling functions are there already?
- morelisp 4y ago
  "I mean it's one mutable string type Michael, what could it take to standardize, 48 pages not including the allocator model?"

by dezgeg 4y ago

pjmlp 4y ago

Inertia is no excuse, if something like SDS was adopted by WG14, eventually C applications could slowly be migrated into it. As it is, it will never happen.

ranger_danger 4y ago
SDS is cool, I use it in my projects and have also extended it further with some new features... but I worry about the amount of dynamic allocation going on, it would be nice to have an alternative solution such as using stack or pool allocations, or being able to declare SDS string literals at compile-time (probably only possible in C++). Every time I notice that I need to replace a const char* with an SDS I just know I'm slowing things down and adding more complexity.
- pjmlp 4y ago
  It doesn't have to be 1:1 equal to SDS, rather at least having WG14 doing something, anything at all, instead of keeping pushing the agenda of C being a Swiss cheese of security exploits, to the point everyone is adopting hardware memory tagging as the ultimate mitigation.

matheusmoreira 4y ago

For some reason C seem to be going through standard updates as often as C++ now. Not only that, they've added absolutely huge stuff like threading primitives as well as an insane generic macro thing. Surely they could add better designed structures and functions for dealing with memory.

duped 4y ago

Copy C++. The underlying string buffer must be null terminated, but still carry its length.

wongarsu 4y ago

You can make the read-only conversion "free" by storing both the size of the string, as well as terminating the actual string contents with a NUL. So the String "bar" would be { length: 3, contents: ['b', 'a', 'r', '\0\] }. All your functions dealing with the "rich" string type work the same using the length, except they have to be aware of the need to preserve the terminating 0, and you if you want to pass a read-only string to a legacy function you can just pass it contents. Of course that also generates a giant foot gun because you might manage to get the old and new strlen to disagree on the size, because one reads the length field and the other searches the \0.

dralley 4y ago

Is that really so big a deal, considering they've done that multiple times already anyway? How many versions of strcpy, printf, and other string handling functions are there already?

morelisp 4y ago
"I mean it's one mutable string type Michael, what could it take to standardize, 48 pages not including the allocator model?"