[Libreoffice-commits] core.git: use startsWith() instead of compareToAscii()

[Thomas Arnhold]

I've corrected it to equals. Thanks Stephan for spotting this!

Thomas

Am 11.03.2013 13:48, schrieb Stephan Bergmann:
> On 03/11/2013 12:56 PM, Lionel Elie Mamane wrote:
>> So,
>>   compareToAscii never returned zero
>> means
>>   url.compareToAscii(..) == 0 never was true
>> so you are saying that
>>   return bEnabled &&
>> url.compareToAscii("sdbc:embedded:hsqldb",sizeof("sdbc:embedded:hsqldb"))
>> == 0
>> was in fact equivalent to
>>   return false;
>>
>> In other words, you are saying that foo.compareToAscii(bar, n) is more
>> or less a
>> memcmp(&foo, &bar, min(strlen(foo),n)); provided foo is long enough it
>> always compares *exactly* n characters/bytes, never less.
>>
>> I *strongly* doubt that, since it would mean that embedded hsqldb .odb
>> files WOULD NOT WORK AT ALL.
>>
>> Indeed, looking in sal/rtl/ustring.cxx at function
>> rtl_ustr_ascii_shortenedCompare_WithLength,
>> it seems to me it handles the terminating NULL specially:
>>
>>      while ( (nShortenedLength > 0) &&
>>              (pStr1 < pStr1End) && *pStr2 )
>>      {
>>         ...
>>      }
>>
>>      (...)
>>
>>      if ( *pStr2 )
>>      {
>>         ...
>>      }
>>      else
>>      {
>>         nRet = pStr1End - pStr1;
>>      }
>>
>> That is, it returns 0 if and only if its first argument (that is, in
>> our example, the value of the url variable) it precisely equal to the
>> pStr2 argument.
>>
>> In other words, I think foo.compareToAscii(bar, n) is more or less a
>>   memcmp(&foo, &bar, min(strlen(foo),strlen(bar),n))
>> that is more or less a
>>   strncmp(&foo, &bar, n)
>> In other words, if bar is of length less than 1000, then all these
>> calls are equivalent:
>>   foo.compareToAscii(bar, sizeof(bar))
>>   foo.compareToAscii(bar, strlen(bar))
>>   foo.compareToAscii(bar, 1000)
>>   foo == bar
>
> Ah, right, indeed.  Even better catch.
>
>>> (and, while we are at it, at least for the initial "sdbc" part, URI
>>> syntax would mandated case-insensitive comparison anyway, unless the
>>> given url is known to be normalized to lowercase),
>>
>> I'm not sure if it is guaranteed normalised. If it is not, we have
>> this bug (of case-sensitivity) all over the place, not only in
>> embedded HSQLDB.
>
> Yes, I guess we have that bug in many places, not only in connectivity.
>   I occasionally notice it and think, ah, that code isn't quite right,
> but rarely bother to do anything about it, mostly because (a) it is
> probably a bug rarely noticed in practice, where everybody writes URI
> schemes in all-lowercase anyway, and (b) often not trivially fixed by
> switching to a case-insensitive comparison function, as often only part
> of a given string shall be compared case insensitively.
>
> Stephan
>