On miÃ, 2011-03-16 at 05:52 -0500, Jonathan Nieder wrote: > Carlos MartÃn Nieto wrote: > > > The GNU C Library (glibc) uses SSE instructions to make strlen (among > > others) faster, loading 4 bytes at a time and reading past the end of > > the allocated memory. This read is safe and when the strlen function > > is inlined, it is (obviously) not replaced by valgrind, which reports > > a false-possitive. > > This still makes no sense to me. How is it possible to inline a > function from glibc? When I look in /usr/include/string.h, I see > > extern size_t strlen (__const char *__s) > __THROW __attribute_pure__ __nonnull ((1)); Looking at that header, strlen is one of the few functions not being replaced by its __builtin version, and I only see __builtin_strlen in the C++ patches. I'll rephrase to something like "Some versions of strlen use SSE which then get inlined" to avoid blaming anyone in particular, though thinking about it, it does seem logical that it's GCC's builtin strlen. > > > Tell valgrind to ignore this particular error, as the read is, in > > fact, safe. > > I'm happy to see a workaround. I would be even happier if it came > with documentation about which versions of valgrind need it. I think 3.6.1 doesn't need it, as Debian's 1:3.5.0+3.6.0svn20100609-1 version is reportedly fixed. I'll see if I can find more information in the valgrind bug tracker. Cheers, cmn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html