3 ms·
std::span came out in C++20, by that logic neither did it help in any way... Personally operator [] should abort by default because otherwise it is redundant w
by sirwhinesalot 3y ago
std::span came out in C++20, by that logic neither did it help in any way...
Personally operator [] should abort by default because otherwise it is redundant with .at()
- gpderetta 3y agoOf course aborting in span::operator[] wouldn't be enough. But bound checking in operator[] for vector, deque, std::array and normal arrays would help (I think it is infeasible to do it for arbitrary pointers).
- jcranmer 3y ago> (I think it is infeasible to do it for arbitrary pointers) I think there's a viable path that could solve it well enough for a safe compiler mode to be feasibly mandated in secure coding standards. Pointer values can come from one of several operations: pointer offsetting, int-to-pointer, address of known object (including especially array-to-pointer decay), uninitialized values, function parameters, struct members, and globals. Safe bounds information is automatic for uninitialized values and addresses of known objects, and pointer offsetting can trivially propagate known bounds. If you had annotations ("the size of this array may be found in variable X"), you could usually get pretty reliably information for the last three categories. The only truly difficult case is int-to-pointer, but from what I've seen in other contexts, it's likely that int-to-pointer in general is just an inherently cursed operation that auto-safe code just shouldn't support.
- gpderetta 3y agoWell, the point is safety for existing code. If you can annotate pointers to match them with their bound you can as easily replace them with a span and avoid needing compiler heroics. Edit: unless you absolutely need the change to be ABI stable, but even then there are ways around that.