"Nelson H. F. Beebe" <[email protected]> writes:
> When I built libidn-1.25 on Fedora release 15 (Lovelock) x86_64 with
> gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
Thanks for building!
> ==6976== Invalid read of size 4
> ==6976== at 0x4C116C5: idna_to_ascii_4z (idna.c:526)
> ==6976== by 0x4C11944: idna_to_ascii_8z (idna.c:579)
> ==6976== by 0x400B15: doit (tst_idna2.c:485)
> ==6976== by 0x40090C: main (utils.c:146)
This is a known problem with glibc (or gcc, see below), its strlen
implementation is optimized to read in 4 bytes chunks so it ends up
reading out of bounds. I have added a libidn.supp valgrind suppressions
file to this release, however I'm considering two other solutions:
1) disable valgrind by default (we have done this for GnuTLS)
2) allocate slightly more than what is needed, so that glibc strlen
can read in 4 byte chunks without triggering valgrind
I'm somewhat leaning towards 2 right now, although we may end up with 1
eventually because using valgrind requires some manual interpretation of
the outcome and this is difficult to do unattended.
> Fortunately, I've built dozens of versions of gcc on our systems, so I
> tried a fresh build with gcc (GCC) 4.4.6 20110301, and all tests then
> passed.
Interesting! I guess this suggests the over-optimized strlen is
actually not in glibc as I previously assumed but in the compiler.
/Simon
_______________________________________________
Help-libidn mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-libidn
