4 ms·

To be clear, I don't think there is any hope of implementing any protections at the language level in C, the push back would be exceptionally fierce. Although I

To be clear, I don't think there is any hope of implementing any protections at the language level in C, the push back would be exceptionally fierce. Although I do agree that a 'slice' type in the stdlib would not be to much to ask for. My comment was more for consideration in the design of new languages, in particular, the development of the frequently cited as not existing, simple, C-like language with memory safety features. In that case, in a green field scenario, there are a few ways to achieve statically known memory-boundary respecting iteration and general access. Further, there are several existing methods of achieving 'generics'. The real design challenge would be in finding the simplest implementation that does not overly burden potential developers. I am confident that it could be done, but it would take some grave dissatisfaction with Rust (which is currently at the top of the adoption curve in the memory safe, but GC free space) for the proposed language to take off.

GrumpySloth 3y ago
The problem with slices in C being added in stdlib would be that they really are a generic data type. It would be similar to atomic types. While C++ could just add std::atomic<T>, C needed to add a special construct: _Atomic(T). C++ already has a slice type. It’s called std::span<T>. Porting it to C would probably require something similar to atomics. At which point I guess you may just as well get on with it and switch to C++.
- pornel 3y ago
  C++ chose not to have bounds checking on span’s operator[] by default. Like with vector, approximately nobody will use .at(). Buffer overflow vulnerabilities are where programmers thought they don’t need a bounds check, so having this as a choice every time, with the safer option looking worse, is working against it. A nice minimal built-in syntax for spans (like Rust’s slices) could be an incentive to keep the bounds checks, and eventually make bare pointer arithmetic stand out as riskier.
  - GrumpySloth 3y ago
    I think this is more of a social problem with C++. Regardless whether the feature is implemented in the standard library or the core language, the broader C++ community is not going to approve of enabling bounds checks on the bracket operator. And whether this operator is implemented as a builtin or as an overload on an stdlib type is basically transparent to the user. FWIW you can enable bounds checks for the bracket operator by default for STL types in GCC and Clang. So for interfacing with Rust it is both obvious how to translate between slices in Rust and std::span in C++, and you can verify to a degree that this std::span isn’t corrupted on C++ side (to a degree).

GrumpySloth 3y ago

The problem with slices in C being added in stdlib would be that they really are a generic data type. It would be similar to atomic types. While C++ could just add std::atomic<T>, C needed to add a special construct: _Atomic(T). C++ already has a slice type. It’s called std::span<T>. Porting it to C would probably require something similar to atomics. At which point I guess you may just as well get on with it and switch to C++.

pornel 3y ago
C++ chose not to have bounds checking on span’s operator[] by default. Like with vector, approximately nobody will use .at(). Buffer overflow vulnerabilities are where programmers thought they don’t need a bounds check, so having this as a choice every time, with the safer option looking worse, is working against it. A nice minimal built-in syntax for spans (like Rust’s slices) could be an incentive to keep the bounds checks, and eventually make bare pointer arithmetic stand out as riskier.
- GrumpySloth 3y ago
  I think this is more of a social problem with C++. Regardless whether the feature is implemented in the standard library or the core language, the broader C++ community is not going to approve of enabling bounds checks on the bracket operator. And whether this operator is implemented as a builtin or as an overload on an stdlib type is basically transparent to the user. FWIW you can enable bounds checks for the bracket operator by default for STL types in GCC and Clang. So for interfacing with Rust it is both obvious how to translate between slices in Rust and std::span in C++, and you can verify to a degree that this std::span isn’t corrupted on C++ side (to a degree).