Hacker News Reader

Comment by GrumpySloth | Hacker News Reader

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++.

View on HN

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.

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).

Reply on news.ycombinator.com