Switch to std::span and add 1 line to std::span::operator[] to check your bounds...
Switch to std::span and add 1 line to std::span::operator[] to check your bounds...
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!
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...
The actual logic of gggp's statement also doesn't make any sense. We as humans also under and overestimate the soundness of programs.
Sometimes, a perfectly fine solution is massaged to better adhere to best practices because we can't convince ourselves that it's correct. Rust requires that we convince the compiler, and then we know it's correct via the compiler's proofs, instead of requiring us to do the proof all the time.
If you zip/print/scan/ocr/train ML on/restore from ML its still piracy even though none of the pixels are directly transferred.
If you then process your requests in the slowest programming language, you add back at least 100x the overhead.
It doesn’t make sense to me.
It also turns out we can’t even verify, in general, the result of integration:
Suppose you are given two functions, f(x) and G(x), and are told that G(x) is an antiderivative of f(x). So then you let g(x) = G’(x), the derivative of G(x).
Now if G(x) is truly an antiderivative of f(x) then we must have g(x) = f(x) but unfortunately the problem of determining whether two functions are equal is undecidable (a consequence of the halting problem).
15 years ago in the US this would have been uncontroversial
Look at the products they make. They try to make stuff that targets the widest market possible; everybody. They try not to go for niche markets.
I think more practically cars have adding driver assistance feature for a while now - more cameras, blind spot monitoring, ultrasound for parking, lane drift indicators.
It is therefore not unreasonable to assume that adding more sensors is helpful (but even the old adage of more data is better than less would probably say that).