From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-12-03 20:02:19
On Tue, Dec 3, 2019 at 11:17 AM Zach Laine via Boost <boost_at_[hidden]>
> On Tue, Dec 3, 2019 at 1:08 PM Emil Dotchevski via Boost <
> boost_at_[hidden]> wrote:
> > On Tue, Dec 3, 2019 at 7:42 AM Zach Laine via Boost <
> > >
> > 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*
> > > 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
> > > what the difference is as you see it.
> > These are two different kinds of errors, invalid access vs buffer
> > 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
> > 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
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk