Re: [Libreoffice-commits] update string copy semantics to be undefined in a non-crashing way

On 10/04/2012 12:28 PM, Norbert Thiebaud wrote:
> On Thu, Oct 4, 2012 at 4:34 AM, Stephan Bergmann <sbergman@redhat.com> wrote:
> > Given that "it is an error for X to happen" and "if X happens, behaviour is
> > undefined" have exactly the same meaning (at least in my understanding of
> > computing), I wonder whether this is just a harmless rephrasing, or whether
> > there is a deeper misunderstanding lurking there.
>
> In my mind there is a distinction:
> if an API declare that something 'an error' I expect it to give a
> return code, an exception, a signal... something bad
> if something is said to be 'undefined', then the call can do anything,
> including nothing or returning random result...

Right, that might account for some confusion.  Probably better to use 
the term "undefined behavior" then, indeed.

> > Note how the original code above prevented problems with overflowing
> > beginIndex + count.
>
> The only exploitable way to misuse that would be to be able to read
> past the input and into memory that contain sensitive / secret
> information... and being able to disclose it that way...
> Although not impossible, it is hard to conceive a scenario where that
> would lead to a practical exploit.
> (by opposition a write overflow is much more likely to lead to a
> practical exploit)

I wasn't especially concerned about security exploits, just wondered why 
the new code introduced this imprecision.

Stephan