5 ms·

Given how nice system programming languages we have these days, I refrain to let classic Null-terminated C-Strings entering my program. Even on embedded program

by ktpsns 2y ago

Given how nice system programming languages we have these days, I refrain to let classic Null-terminated C-Strings entering my program. Even on embedded programming we opt-in for std::string (over Arduino's String). I am just happy to save our time in favour of having some X percentage less optimal code.

pasc1878 2y ago
Depending on your usage it is not necessarily less optimal either. You never need to walk the string to find the \0 byte. e.g. for strlen. For short strings no heap memory needs to be allocated or deallocated.
- account42 2y ago
  It's really too bad though that the short string optimization capacity is neither standardized nor user-controlled.
tialaramex 2y ago
It is seriously unfortunate that C++ managed to standardize std::string, a not-very-good owning container type, but not (until much, much later) std::string_view, the non-owning slice type you need far more often. Even if Rust had chosen to make &str literally just mean &[u8] rather than promising it is UTF-8 text, the fact &str existed in Rust 1.0 was a huge win. Every API that doesn't care who owns the textual data can ask you for this non-owning slice type, where in C++ it had to either insist on caring about ownership (std::string) or resort to 1970s hacks and take char * with zero terminated strings. And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it.
- roelschroeven 2y ago
  > And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it. I don't think this in itself is a real problem. You pay for the zero at the end, which is not much. The real cost of zero termination is having to scan the whole string to find out the size, which with std::string is only needed when using it with C-style APIs.
  - wmanley 2y ago
    and also you have to copy (probably allocating) to get a substring.
    - account42 2y ago
      Only if you want a substring with separate ownership though - a string_view doesn't have to be NUL-terminated.
      - jabl 2y ago
        If you want to pass the string_view to some API that expects NULL terminated strings, then a copy is necessary (well, maybe is some cases you can cheat by writing a NULL in the string and remembering the original character, and then after the API call restore the character). This isn't as much a fault of a string_view type of mechanism, but rather API's wanting NULL terminated strings. Which are kind of hard to avoid on mainstream systems today, even at the syscall interface. Oh well..
        account42 2y ago
        Sure, but the thread here was about the forced NUL-terminator in std::string and the costs associated with that. If you want a NUL-terminator (e.g. for use with a C API) then you have to pay the copy (and in the general case, allocation) cost for substrings no matter how your internal strings look (unless you can munge the original string) and std::string is exactly the right abstraction for you. But yeah, it would be nice if the kernel and POSIX APIs had better support for pointer+size strings.
- bobmcnamara 2y ago
  > And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it. Is this required now? I've seen a system where this was only null terminated after calling .c_str()
  - nmeofthestate 2y ago
    c_str has to be constant complexity, so I guess the memory needs to be already allocated for that null character. I'd be surprised to see an implementation that doesn't just ensure that \0 is there all the time.
    - bobmcnamara 2y ago
      Ah, the system I ran into would've been pre-c++11. Only saw it trying to debug a heap issue and I was surprised because I thought surely it's a null terminated string already right? They also checked the heap allocation size, so it would only reallocate if the length of string data % 8 was zero.
  - tialaramex 2y ago
    Facebook / Meta had their own string type which did this, turns out now you have an exciting bug because you end up assuming uninitialized values have properties but they don't, reading an uninitialized value is Undefined Behaviour and so your stdlib conspires with the OS to screw you in some corner cases you'd never even thought about because that saved them a few CPU cycles. The bug will be crazy rare, but of course there are a lot of Facebook users, so if one transaction out of a billion goes haywire, and you have 100M users doing 100 transactions on average, the bug happens ten times. Good luck.
- mjevans 2y ago
  Golang's slices view of the world is addictive.
kazinator 2y ago
If someone ever has to use your stuff over FFI from a high level language, they will curse you for not just using C strings.
- gpderetta 2y ago
  Null terminated C strings are still terrible for FFI. Pointer and length is a better solution and it is trivially interoperable with code that uses, say, string_view.
raverbashing 2y ago
Exactly this It seems C is going around in circles while everybody else has moved on No, speed and "efficiency" are not a be-all, for-all. Safety is more important than that except in very specific cases. And even in these cases there are better ways and libraries to deal with this issue without requiring the use of "official" newer C functions that seem to still be half broken There's so much fiction regarding memory issues and limited memory issues and what to do if we hit limited memory issues when in practice terminate and give up is the (often enforced by the OS) norm.
- saagarjha 2y ago
  I look forward to your solution to bridge these libraries to every other person’s slightly different implementation of the same library, which also has to talk to every other interface that cropped up over the last 50 years and takes null-terminated strings anyways.
- shrimp_emoji 2y ago
  I haven't moved on. :> C FTW! Bloated langs are cringe.
  - raverbashing 2y ago
    Have fun playing with a chainsaw with the safety disabled
    - John_Cena 2y ago
      Have fun playing with your Fischer Price KidSafe™ playset? >:) At some point we are just outlining in general terms what we want from a language. If C was a toolbox it is a limited number of essential tools, other languages add so many things Alton Brown would faint from the unitasking nature of them. C programmers love this. I know I do.
      - raverbashing 2y ago
        The "kids tool" comment is so weird. I could do pretty much whatever I wanted in (DOS) user space with Pascal. I can do pretty much whatever I want in a modern OS user space with whatever lang I prefer. "Oh but you might need C bindings" because the OS was build that way! (And with Windows/COM you might prefer a C++ bindings - just saying ;) ) > If C was a toolbox it is a limited number of essential tools C is an old toolbox where 1/3 of them is a rusty finger-remover, 1/3 is a clunky barely do nothing metal crap and 1/3 of them kinda works I'm all for a simplified set of essential tools, but not one where it's sharper on the user handle than it is on the business end bUt C iS jUsT hIgH lEvEl aSsEmBlY no it is not

by ktpsns 2y ago

pasc1878 2y ago

Depending on your usage it is not necessarily less optimal either. You never need to walk the string to find the \0 byte. e.g. for strlen. For short strings no heap memory needs to be allocated or deallocated.

account42 2y ago
It's really too bad though that the short string optimization capacity is neither standardized nor user-controlled.

tialaramex 2y ago

It is seriously unfortunate that C++ managed to standardize std::string, a not-very-good owning container type, but not (until much, much later) std::string_view, the non-owning slice type you need far more often. Even if Rust had chosen to make &str literally just mean &[u8] rather than promising it is UTF-8 text, the fact &str existed in Rust 1.0 was a huge win. Every API that doesn't care who owns the textual data can ask you for this non-owning slice type, where in C++ it had to either insist on caring about ownership (std::string) or resort to 1970s hacks and take char * with zero terminated strings. And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it.

roelschroeven 2y ago
> And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it. I don't think this in itself is a real problem. You pay for the zero at the end, which is not much. The real cost of zero termination is having to scan the whole string to find out the size, which with std::string is only needed when using it with C-style APIs.
- wmanley 2y ago
  and also you have to copy (probably allocating) to get a substring.
  - account42 2y ago
    Only if you want a substring with separate ownership though - a string_view doesn't have to be NUL-terminated.
    - jabl 2y ago
      If you want to pass the string_view to some API that expects NULL terminated strings, then a copy is necessary (well, maybe is some cases you can cheat by writing a NULL in the string and remembering the original character, and then after the API call restore the character). This isn't as much a fault of a string_view type of mechanism, but rather API's wanting NULL terminated strings. Which are kind of hard to avoid on mainstream systems today, even at the syscall interface. Oh well..
      - account42 2y ago
        Sure, but the thread here was about the forced NUL-terminator in std::string and the costs associated with that. If you want a NUL-terminator (e.g. for use with a C API) then you have to pay the copy (and in the general case, allocation) cost for substrings no matter how your internal strings look (unless you can munge the original string) and std::string is exactly the right abstraction for you. But yeah, it would be nice if the kernel and POSIX APIs had better support for pointer+size strings.
bobmcnamara 2y ago
> And then in modern C++ std::string cares about and preserves the stupid C-style zero termination anyway, so you're paying for it even if you never use it. Is this required now? I've seen a system where this was only null terminated after calling .c_str()
- nmeofthestate 2y ago
  c_str has to be constant complexity, so I guess the memory needs to be already allocated for that null character. I'd be surprised to see an implementation that doesn't just ensure that \0 is there all the time.
  - bobmcnamara 2y ago
    Ah, the system I ran into would've been pre-c++11. Only saw it trying to debug a heap issue and I was surprised because I thought surely it's a null terminated string already right? They also checked the heap allocation size, so it would only reallocate if the length of string data % 8 was zero.
- tialaramex 2y ago
  Facebook / Meta had their own string type which did this, turns out now you have an exciting bug because you end up assuming uninitialized values have properties but they don't, reading an uninitialized value is Undefined Behaviour and so your stdlib conspires with the OS to screw you in some corner cases you'd never even thought about because that saved them a few CPU cycles. The bug will be crazy rare, but of course there are a lot of Facebook users, so if one transaction out of a billion goes haywire, and you have 100M users doing 100 transactions on average, the bug happens ten times. Good luck.
mjevans 2y ago
Golang's slices view of the world is addictive.

kazinator 2y ago

If someone ever has to use your stuff over FFI from a high level language, they will curse you for not just using C strings.

gpderetta 2y ago
Null terminated C strings are still terrible for FFI. Pointer and length is a better solution and it is trivially interoperable with code that uses, say, string_view.

raverbashing 2y ago

Exactly this It seems C is going around in circles while everybody else has moved on No, speed and "efficiency" are not a be-all, for-all. Safety is more important than that except in very specific cases. And even in these cases there are better ways and libraries to deal with this issue without requiring the use of "official" newer C functions that seem to still be half broken There's so much fiction regarding memory issues and limited memory issues and what to do if we hit limited memory issues when in practice terminate and give up is the (often enforced by the OS) norm.

saagarjha 2y ago
I look forward to your solution to bridge these libraries to every other person’s slightly different implementation of the same library, which also has to talk to every other interface that cropped up over the last 50 years and takes null-terminated strings anyways.
shrimp_emoji 2y ago
I haven't moved on. :> C FTW! Bloated langs are cringe.
- raverbashing 2y ago
  Have fun playing with a chainsaw with the safety disabled
  - John_Cena 2y ago
    Have fun playing with your Fischer Price KidSafe™ playset? >:) At some point we are just outlining in general terms what we want from a language. If C was a toolbox it is a limited number of essential tools, other languages add so many things Alton Brown would faint from the unitasking nature of them. C programmers love this. I know I do.
    - raverbashing 2y ago
      The "kids tool" comment is so weird. I could do pretty much whatever I wanted in (DOS) user space with Pascal. I can do pretty much whatever I want in a modern OS user space with whatever lang I prefer. "Oh but you might need C bindings" because the OS was build that way! (And with Windows/COM you might prefer a C++ bindings - just saying ;) ) > If C was a toolbox it is a limited number of essential tools C is an old toolbox where 1/3 of them is a rusty finger-remover, 1/3 is a clunky barely do nothing metal crap and 1/3 of them kinda works I'm all for a simplified set of essential tools, but not one where it's sharper on the user handle than it is on the business end bUt C iS jUsT hIgH lEvEl aSsEmBlY no it is not