bug#56413: [PATCH 1/1] scm_i_utf8_string_hash: compute u8 chars not bytes

[Rob Browning <rlb@defaultvalue.org>]

Ludovic Courtès <ludo@gnu.org> writes:

> Rob Browning <rlb@defaultvalue.org> skribis:

>> +  // Make sure a utf-8 symbol has the expected hash.  In addition to
>> +  // catching algorithmic regressions, this would have caught a
>> +  // long-standing buffer overflow.
>> +
>> +  // περί
>> +  char about_u8[] = {0xce, 0xa0, 0xce, 0xb5, 0xcf, 0x81, 0xce, 0xaf, 0};
>> +  SCM sym = scm_from_utf8_symbol (about_u8);
>> +
>> +  const unsigned long expect = 4029223418961680680;
>> +  const unsigned long actual = scm_to_ulong (scm_symbol_hash (sym));
>
> Is this a documented example of Jenkins?  Or did you use a reference
> implementation?

OK, so unfortunately I don't actually recall how I came up with that
number, but I can start over with some canonical approach to compute the
value if we like.

...if I didn't get it from somewhere more authoritative, I might also
have just been trying to at least prevent undetected regressions.

> AFAICS this will only change the hash of UTF-8 symbols and won’t have
> any effect on the output of ‘string-hash’, right?  If not that would be
> an incompatibility.

The u8_mbsnlen() change should strictly fix bugs I think?  i.e. if the
length is supposed to be in characters, which it looks like from all the
other uses in the function (and from the comment), then the old code
was returning the wrong values (which prompted the original crashes).

So this change *could* alter results, but only for non-ASCII strings,
and those results would have been wrong (i.e. relying on uninitialized
memory).  Of course if that memory was *always* the same for a given
symbol somewhow (everywhere in memory), then the result would be stable,
if incorrect.


That leaves the size_t -> long change in scm_i_str2symbol(), and I don't
think that has anything to do with UTF-8, but it could cause mangling of
the value on any platform where the data types differ sufficiently, and
then of course if we're not using the same type consistently, then we
could give different answers for the same symbol in different contexts
(for different code paths).

And indeed, looks like I missed another case; just below in
scm_i_str2uninterned_symbol() we also use size_t.  For now, I suspect we
should change both or neither, and definitely change them all to match
"eventually".

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4