[Libreoffice-commits] update string copy semantics to be undefined in a non-crashing way
sbergman at redhat.com
Thu Oct 4 05:48:34 PDT 2012
On 10/04/2012 12:28 PM, Norbert Thiebaud wrote:
> On Thu, Oct 4, 2012 at 4:34 AM, Stephan Bergmann <sbergman at 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.
More information about the LibreOffice