4 ms·

I think most modern languages shifted towards slices due to security issues with sentinels. C++ span, rust, zig, go. It's very sad we need to use libc interface

by bvrmn 6y ago

I think most modern languages shifted towards slices due to security issues with sentinels. C++ span, rust, zig, go. It's very sad we need to use libc interfaces and deal with null terminated byte sequences.

dnautics 6y ago
Zig as of 0.6.0 supports both sentinels and length.
steveklabnik 6y ago
Not just security issues, it also makes substrings zero copy.
- mehrdadn 6y ago
  It also makes it possible to have nulls inside a string.
  - saagarjha 6y ago
    This is usually a bad idea, FWIW.
    - mehrdadn 6y ago
      I mean, I wasn't trying to suggest you intentionally inject nulls in your strings for no reason! But that doesn't mean your data types should unexpectedly break if this ends up happening...
      - saagarjha 6y ago
        Generally my policy with std::string and NULs is "don't, ever" because someone is going to call c_str() on it and pass it to a C API, and bad things are going to happen. If you need to embed \0, then use std::vector<char>. Of course, you do get the slight benefit that in the cases where you don't call C APIs you won't have bad things happen, but I wouldn't could on that.
        mehrdadn 6y ago
        Again, this isn't about whether you go out of your way to insert it, but about whether the data type should be able to handle it regardless.
    - bjoli 6y ago
      I'll just leave this here: https://youtu.be/5dhSN9aEljg https://youtu.be/5dhSN9aEljg
- Someone 6y ago
  That can be problematic, too. If your language has a garbage collector, it may mean tiny substrings keep huge strings alive. Java moved away from using slices (https://dzone.com/articles/changes-stringsubstring-java-7 https://dzone.com/articles/changes-stringsubstring-java-7), I think for that reason. If your language isn’t garbage collected, it can cause problems if the substring must outlive the string it was extracted from. That means that, for some functions, you’ll have to decide whether to return the slice or make the copy. (In Rust, that means the slice has a different ‘type’ (not sure what they call it), that of a string whose lifetime is bound to the original string, and the compiler will check that you won’t make the mistake of having the slice outlive it’s source)
  - steveklabnik 6y ago
    Yep, all good points! (And yeah, you're right about Rust too; string slices are a different type than owned strings.)
  - xfer 6y ago
    How huge typical strings are that this is a problem? It could be a problem for arrays but seems unlikely for strings.
    - Someone 6y ago
      Some strings start live as part of multi-megabyte text files that get slurped in. Happened quite a bit with HTML/XML parsers. Workaround was to do new String(s.substring(…)) about everywhere. Real world case (with few details) at https://stackoverflow.com/questions/10951812/java-not-garbage-collecting-memory https://stackoverflow.com/questions/10951812/java-not-garbag.... Also, using slices doesn’t come for free; it makes all String objects larger because, apart from the reference to the underlying character array, an offset and length must be kept around.

by bvrmn 6y ago

dnautics 6y ago

Zig as of 0.6.0 supports both sentinels and length.

steveklabnik 6y ago

Not just security issues, it also makes substrings zero copy.

mehrdadn 6y ago
It also makes it possible to have nulls inside a string.
- saagarjha 6y ago
  This is usually a bad idea, FWIW.
  - mehrdadn 6y ago
    I mean, I wasn't trying to suggest you intentionally inject nulls in your strings for no reason! But that doesn't mean your data types should unexpectedly break if this ends up happening...
    - saagarjha 6y ago
      Generally my policy with std::string and NULs is "don't, ever" because someone is going to call c_str() on it and pass it to a C API, and bad things are going to happen. If you need to embed \0, then use std::vector<char>. Of course, you do get the slight benefit that in the cases where you don't call C APIs you won't have bad things happen, but I wouldn't could on that.
      - mehrdadn 6y ago
        Again, this isn't about whether you go out of your way to insert it, but about whether the data type should be able to handle it regardless.
  - bjoli 6y ago
    I'll just leave this here: https://youtu.be/5dhSN9aEljg https://youtu.be/5dhSN9aEljg
Someone 6y ago
That can be problematic, too. If your language has a garbage collector, it may mean tiny substrings keep huge strings alive. Java moved away from using slices (https://dzone.com/articles/changes-stringsubstring-java-7 https://dzone.com/articles/changes-stringsubstring-java-7), I think for that reason. If your language isn’t garbage collected, it can cause problems if the substring must outlive the string it was extracted from. That means that, for some functions, you’ll have to decide whether to return the slice or make the copy. (In Rust, that means the slice has a different ‘type’ (not sure what they call it), that of a string whose lifetime is bound to the original string, and the compiler will check that you won’t make the mistake of having the slice outlive it’s source)
- steveklabnik 6y ago
  Yep, all good points! (And yeah, you're right about Rust too; string slices are a different type than owned strings.)
- xfer 6y ago
  How huge typical strings are that this is a problem? It could be a problem for arrays but seems unlikely for strings.
  - Someone 6y ago
    Some strings start live as part of multi-megabyte text files that get slurped in. Happened quite a bit with HTML/XML parsers. Workaround was to do new String(s.substring(…)) about everywhere. Real world case (with few details) at https://stackoverflow.com/questions/10951812/java-not-garbage-collecting-memory https://stackoverflow.com/questions/10951812/java-not-garbag.... Also, using slices doesn’t come for free; it makes all String objects larger because, apart from the reference to the underlying character array, an offset and length must be kept around.