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?).