Crash test update

Stephan Bergmann sbergman at redhat.com
Fri Feb 13 03:13:26 PST 2015


On 02/13/2015 10:26 AM, Caolán McNamara wrote:
> The new ppt crashes and maybe some others are due to the new asserts in
> sal strings, and are "fixed" by f78fa7e9c72ab1bd3e6a19d5234651f379c44a08
>
> I'll leave it to sberg/mst as to if it is reasonable or not to expect
> that the argument to O[U]String::match needs to be within the range of
> the OUString

Note that 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=f78fa7e9c72ab1bd3e6a19d5234651f379c44a08> 
"apparently calling match on a string with an index past the end is now 
fatal" would have been a true fix even without 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=b0ef5cf258f3a84054c052f0a09a208dbc17fdf3> 
"sal: add some argument checking assertions for strings and buffers." 
The code called rtl_ustr_shortenedCompare_WithLength() with pStr1 
pointing into memory past aDocBase and with negative nStr1Len, so in the 
MSVC sizeof(IMPL_RTL_STRCODE)==sizeof(wchar_t) case called wcsncmp() 
with an invalid first pointer and a huge (size_t) size.

As to whether the preconditions of the various OUString functions are 
reasonable, that's for sure debatable (and has been debated in the past, 
if I remember correctly).  The one advantage I see of having strict 
preconditions for all the functions is that it keeps things uniform and 
evades API design decisions of how to behave for "odd" arguments (is the 
fromIndex argument to match() implicitly increased to zero if negative? 
is copy() returning a reversed result if its count argument is negative?).


More information about the LibreOffice mailing list