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

[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