4 ms·

You've compiled with _LIBCPP_HARDENING_MODE_FAST, which still adds some extra checks not required by the standard.[1] You can also tell it's nonstandard because

You've compiled with _LIBCPP_HARDENING_MODE_FAST, which still adds some extra checks not required by the standard.[1] You can also tell it's nonstandard because it doesn't really throw out_of_range, it just traps. > Fast mode, which contains a set of security-critical checks that can be done with relatively little overhead in constant time and are intended to be used in production. > Using std::span as an example, setting the hardening mode to fast will always enable the valid-element-access checks when accessing elements via a std::span object, but whether dereferencing a std::span iterator does the equivalent check depends on the ABI configuration. 1: https://libcxx.llvm.org/Hardening.html https://libcxx.llvm.org/Hardening.html

dataflow 2y ago
> You've compiled with _LIBCPP_HARDENING_MODE_FAST, which still adds some extra checks not required by the standard. The standard doesn't require any checks to begin with. It also doesn't require optimizations.
- deleted 2y ago
  [deleted]
- debugnik 2y ago
  It does, on explicitly bounds-checked accessors like .at, which span is gaining for C++26. But you originally implied using span was sufficient, you didn't mention LLVM's libc++ hardening. (You even mentioned iterators which, I just quoted, might not be bounds-checked on fast mode either.)
  - dataflow 2y ago
    > It does, on explicitly bounds-checked accessors like .at, which span is gaining for C++26. When I said "the standard doesn't require this" I clearly was not referring to C++26, which does not even exist yet. In any case, I'm not sure what the point of this pedantry is. I'm pretty sure the point was clear. > But you originally implied using span was sufficient, you didn't mention LLVM's libc++ hardening. Because this isn't LLVM-specific, every major STL has bounds checking. You just gotta enable it for your toolchain. Sorry I didn't list every single flag, I guess? > (You even mentioned iterators which, I just quoted, might not be bound-checked on fast mode either.) Which is why I had _LIBCPP_ABI_BOUNDED_ITERATORS, right? I'm not on HN to write comprehensive documentation for every toolchain, I'm just writing a quick tip for people to look into. All this pedantic quibbling over "this isn't required by the standard by default" is just pointless arguing for the sake of arguing on the internet. For all the performance freaks who really care about this: no language I know of guarantees optimizations in the standard, so if you're relying on optimized performance, you're already doing nonstandard stuff. And practically every major compiled language you love or hate has a way to enable or disable bounds checking, letting you violate their "standard" one way or another. D itself has -boundscheck, C++ has toolchain-specific flags, Go has -gcflags=-B, etc...
    - debugnik 2y ago
      So your first answer to being told your initial suggestion is insufficient for bounds-checking was to share a godbolt link without elaborating on where the checking was actually coming from; and when I elaborate, for other readers' sake, not yours, on your solution and other comparable ones, you get defensive and repeatedly call me pedant. Ok, but you know, these discussion are for everyone else to read and maybe learn something too, not just us. As for the bounds-checked accessors, I mentioned them because they already exist in current C++ for other collections, they're coming to the one you suggested using, and I thought them relevant to a discussion about C++ lacking spatial safety.
    - carbotaniuman 2y ago
      I've used vendor-specific C++ compilers with no bounds checking and a barely conforming stdlib, so by your logic C++ has zero bounds checking... Defaults matter!
      - dataflow 2y ago
        > I've used vendor-specific C++ compilers with no bounds checking and a barely conforming stdlib, so by your logic C++ has zero bounds checking... I literally said exactly that: "The standard doesn't require any checks to begin with." > Defaults matter! Sigh... nobody claimed otherwise. You're really missing the point of the thread. All I did was give people a tip on how to improve their code security. The exact sentence I wrote was: >> "If you want bounds checking in your own code, start replacing T* with std::span<T> or std::span<T>::iterator whenever the target is an array." "BUT DEFAULTS MATTER!!!", you rebut! Well OK, then I guess keep your raw pointers in and don't migrate your code? Sorry I tried to help!
        carbotaniuman 2y ago
        Cool, let me know how to improve the code security on my vendor compiler then, I'll be waiting.
        dataflow 2y ago

dataflow 2y ago

> You've compiled with _LIBCPP_HARDENING_MODE_FAST, which still adds some extra checks not required by the standard. The standard doesn't require any checks to begin with. It also doesn't require optimizations.

deleted 2y ago
[deleted]
debugnik 2y ago
It does, on explicitly bounds-checked accessors like .at, which span is gaining for C++26. But you originally implied using span was sufficient, you didn't mention LLVM's libc++ hardening. (You even mentioned iterators which, I just quoted, might not be bounds-checked on fast mode either.)
- dataflow 2y ago
  > It does, on explicitly bounds-checked accessors like .at, which span is gaining for C++26. When I said "the standard doesn't require this" I clearly was not referring to C++26, which does not even exist yet. In any case, I'm not sure what the point of this pedantry is. I'm pretty sure the point was clear. > But you originally implied using span was sufficient, you didn't mention LLVM's libc++ hardening. Because this isn't LLVM-specific, every major STL has bounds checking. You just gotta enable it for your toolchain. Sorry I didn't list every single flag, I guess? > (You even mentioned iterators which, I just quoted, might not be bound-checked on fast mode either.) Which is why I had _LIBCPP_ABI_BOUNDED_ITERATORS, right? I'm not on HN to write comprehensive documentation for every toolchain, I'm just writing a quick tip for people to look into. All this pedantic quibbling over "this isn't required by the standard by default" is just pointless arguing for the sake of arguing on the internet. For all the performance freaks who really care about this: no language I know of guarantees optimizations in the standard, so if you're relying on optimized performance, you're already doing nonstandard stuff. And practically every major compiled language you love or hate has a way to enable or disable bounds checking, letting you violate their "standard" one way or another. D itself has -boundscheck, C++ has toolchain-specific flags, Go has -gcflags=-B, etc...
  - debugnik 2y ago
    So your first answer to being told your initial suggestion is insufficient for bounds-checking was to share a godbolt link without elaborating on where the checking was actually coming from; and when I elaborate, for other readers' sake, not yours, on your solution and other comparable ones, you get defensive and repeatedly call me pedant. Ok, but you know, these discussion are for everyone else to read and maybe learn something too, not just us. As for the bounds-checked accessors, I mentioned them because they already exist in current C++ for other collections, they're coming to the one you suggested using, and I thought them relevant to a discussion about C++ lacking spatial safety.
  - carbotaniuman 2y ago
    I've used vendor-specific C++ compilers with no bounds checking and a barely conforming stdlib, so by your logic C++ has zero bounds checking... Defaults matter!
    - dataflow 2y ago
      > I've used vendor-specific C++ compilers with no bounds checking and a barely conforming stdlib, so by your logic C++ has zero bounds checking... I literally said exactly that: "The standard doesn't require any checks to begin with." > Defaults matter! Sigh... nobody claimed otherwise. You're really missing the point of the thread. All I did was give people a tip on how to improve their code security. The exact sentence I wrote was: >> "If you want bounds checking in your own code, start replacing T* with std::span<T> or std::span<T>::iterator whenever the target is an array." "BUT DEFAULTS MATTER!!!", you rebut! Well OK, then I guess keep your raw pointers in and don't migrate your code? Sorry I tried to help!
      - carbotaniuman 2y ago
        Cool, let me know how to improve the code security on my vendor compiler then, I'll be waiting.
        dataflow 2y ago