Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.