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

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