4 ms·

That responsibility - for passing the correct buffer size - is one of the issues. I have seen many bugs where the caller simply passed the wrong size to strncpy

That responsibility - for passing the correct buffer size - is one of the issues. I have seen many bugs where the caller simply passed the wrong size to strncpy. If you have a fixed-size buffer then the compiler can infer the size for you, thus making this class of bugs go away entirely. TL;DR - I've reviewed enough code to know that software developers pass the wrong size to strncpy and friends.

hzhou321 8y ago
So you need a data structure (or language) that have size embedded in, and the knowledge (and restrictions) of that data structure need to spread to every libraries or function that one use (we are talking about string handling here). It appears to me that you have cornered yourself that the only solution is to modify C/C++ standards to redefine string handling. I am not saying that is bad. But solutions already exist. One is using the string class, another being transiting to a dynamic language (having size as part of data structure and checking it at every usage is one step into dynamic types). Alternatively, the compiler can take over this responsibility by statically check every call (the rust solution). That is a different language. On that, I have a question: how can we pass the syntactic buffer size into a static library without embedding the size into the data? If we do embedding the size, then it is still dynamic within the context of the library. Either way, one should not still be discussing the safety of strncpy here. Now as long as we are discussing strncpy, I assume it is given that we do not want to have buffer size as permanent part of the simple string type and we are not looking for any solutions that demand an overhaul of the language/libraries. I assume it is given that caller takes the responsibility of buffer size -- exchange with a bit responsibility for simpler system and greater control. You won't have a good solution (or good discussions) without confining our context first.
- sevensor 8y ago
  You're quite right, it's important to set the context. But no matter what context you pick, your choice is costly: * We're going to stick with C and its standard library: lots of room to continue to make errors. * We're going to stick with C, but it's OK to consider an alternate implementation of strings: the C standard, the standard library, and lots of other C libraries are full of functions that deal in char* strings, so you're stuck with them. Also, runtime overhead increases. * We're willing to consider other languages: other languages have compiler overhead, semantic overhead, runtime overhead, or all three. Also, you still have to interoperate with C.
  - pjmlp 8y ago
    Even as advocate of mostly safe systems languages I don't see a way of replacing C in the context of UNIX based platforms. So the main issue is how to make C devs actually adopt some kind of safer C dialect and migrate towards it.
    - deleted 8y ago
      [deleted]
    - jstimpfle 8y ago
      Barely related, I had a good laugh when Ori Bernstein (creator of Myrddin, look them up) was asked, "So, is your language memory safe?". -"No, it's memory dangerous". I can't quite tell why, but I found it kind of insightful and it made me feel a little better about my own inclination to work on lower levels.
      - pjmlp 8y ago
        Myrddin looks interesting, thanks for sharing. And I also find funny the remark. :)

hzhou321 8y ago

So you need a data structure (or language) that have size embedded in, and the knowledge (and restrictions) of that data structure need to spread to every libraries or function that one use (we are talking about string handling here). It appears to me that you have cornered yourself that the only solution is to modify C/C++ standards to redefine string handling. I am not saying that is bad. But solutions already exist. One is using the string class, another being transiting to a dynamic language (having size as part of data structure and checking it at every usage is one step into dynamic types). Alternatively, the compiler can take over this responsibility by statically check every call (the rust solution). That is a different language. On that, I have a question: how can we pass the syntactic buffer size into a static library without embedding the size into the data? If we do embedding the size, then it is still dynamic within the context of the library. Either way, one should not still be discussing the safety of strncpy here. Now as long as we are discussing strncpy, I assume it is given that we do not want to have buffer size as permanent part of the simple string type and we are not looking for any solutions that demand an overhaul of the language/libraries. I assume it is given that caller takes the responsibility of buffer size -- exchange with a bit responsibility for simpler system and greater control. You won't have a good solution (or good discussions) without confining our context first.

sevensor 8y ago
You're quite right, it's important to set the context. But no matter what context you pick, your choice is costly: * We're going to stick with C and its standard library: lots of room to continue to make errors. * We're going to stick with C, but it's OK to consider an alternate implementation of strings: the C standard, the standard library, and lots of other C libraries are full of functions that deal in char* strings, so you're stuck with them. Also, runtime overhead increases. * We're willing to consider other languages: other languages have compiler overhead, semantic overhead, runtime overhead, or all three. Also, you still have to interoperate with C.
- pjmlp 8y ago
  Even as advocate of mostly safe systems languages I don't see a way of replacing C in the context of UNIX based platforms. So the main issue is how to make C devs actually adopt some kind of safer C dialect and migrate towards it.
  - deleted 8y ago
    [deleted]
  - jstimpfle 8y ago
    Barely related, I had a good laugh when Ori Bernstein (creator of Myrddin, look them up) was asked, "So, is your language memory safe?". -"No, it's memory dangerous". I can't quite tell why, but I found it kind of insightful and it made me feel a little better about my own inclination to work on lower levels.
    - pjmlp 8y ago
      Myrddin looks interesting, thanks for sharing. And I also find funny the remark. :)