On Tue, Dec 3, 2019 at 11:17 AM Zach Laine via Boost <boost@lists.boost.org> wrote:
On Tue, Dec 3, 2019 at 1:08 PM Emil Dotchevski via Boost < boost@lists.boost.org> wrote:
On Tue, Dec 3, 2019 at 7:42 AM Zach Laine via Boost < boost@lists.boost.org
wrote:
Thus (assuming we're appending into one of the existing buffers instead), *someone* needs to do a range check at runtime, and forgetting it is a serious security vulnerability. If we lived in a world where sanitisers were readily available, reliable, and automatically run on all code, then maybe you can argue that this is the user's responsibility and UB is "safe". We still do not yet live in that world.
I get the point you're making. What I do not get is why you *only* apply it to op+. That is, if memory is so essential for op+, then why is it not also essential for op[] . This is not a troll. I really do want to know what the difference is as you see it.
These are two different kinds of errors, invalid access vs buffer overrun. I trust you're not arguing that these are essentially the same.
Logically, using a bad index can not be recovered from. You have broken invariants, or worse. It's the textbook example of what not to do.
In contrast, when running out of a resource, nothing bad has yet happened. The program is in good state, failing to establish a new invariant. Generally, programs should be able to recover from such state. It's the textbook example for good practices: you check for errors and recover from them, rather than end up with UB.
I buy that in the abstract. For instance, I have no problem with throwing on allocation failure. Where we disagree seems to be whether char[N] is a resource. I claim that it is not.
I thought you're arguing that bad indexing and buffer overrun should be treated the same. I explained why not.