On 10/04/2012 12:28 PM, Norbert Thiebaud wrote:
On Thu, Oct 4, 2012 at 4:34 AM, Stephan Bergmann <sberg...@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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
