Ludovic Courtès <l...@gnu.org> writes: > Rob Browning <r...@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