|
Boost : |
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-12-03 19:17:54
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 <boost_at_[hidden]
> >
> 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.
Zach
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk