I compiled a fresh valgrind-3.7.0 on an x86_64 box running Fedora release 14 with the stock
/lib64/libc-2.13.so that comes with that release.  When I run valgrind, I get what I think are spurious
errors of the form:

==11094== Invalid read of size 8
==11094==    at 0x325C887D74: __GI___strncasecmp_l (in /lib64/libc-2.13.so)
==11094==    by 0x325C83A032: ____strtof_l_internal (in /lib64/libc-2.13.so)
==11094==    by 0x4E0DF1: <somewhere in my code>

(I think the errors are spurious because I can insert a call to strlen () prior to the call to
strtof () in my source without getting any additional errors.  If the string in question wasn't
properly null terminated, the strlen () would show an invalid read error after it fell off of the
end of the string.  I'm assuming that libc's strtof and strncasecmp_l implementations are
bug-free, and merely optimized to read 8 bytes at a time.)

Looking in the valgrind sources at memcheck/mc_replace_strmem.c, I see:

#if defined(VGO_linux)
 STRNCASECMP_L(VG_Z_LIBC_SONAME, strncasecmp_l)
 STRNCASECMP_L(VG_Z_LIBC_SONAME, __GI_strncasecmp_l)
 ...

It looks to me like a third alias for strncasecmp_l, with more underscores, is needed:

#if defined(VGO_linux)
 STRNCASECMP_L(VG_Z_LIBC_SONAME, strncasecmp_l)
 STRNCASECMP_L(VG_Z_LIBC_SONAME, __GI_strncasecmp_l)
 STRNCASECMP_L(VG_Z_LIBC_SONAME, __GI___strncasecmp_l)
  ...

If I rebuild valgrind with the above line added and rerun my program under valgrind, the
spurious errors go away.

If this looks reasonable, it would be great if someone could add it to a future release.

Thanks for working on valgrind -- it's a lifesaver!