Eric Blake <[email protected]> writes: > Simon Josefsson <simon <at> josefsson.org> writes: > >> >> + * tests/test-strstr.c: Add another self-test. >> >> { >> >> + /* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521737 */ >> >> + char *input = strdup ("aBaaaaaaaaaaax"); >> > >> > Did you take the proper precautions to ensure strdup is available? I'd >> > almost feel better if you rewrote this to use malloc/strcpy, rather than >> > dragging in dependencies just for the test. >> >> Good point. Pushed. > > Thanks. But thinking about it more, this doesn't tickle the memchr bug > unless > you are running under efence or other memory checker, so even on platforms > where the bug is still present, we are not likely to get failure reports. > Remember, the bug is that memchr dereferences too much memory when the result > is found early, but this is only fatal if the dereferenced memory was > unreadable in the first place. What would be better would be using Bruno's > recent addition of tests/zerosize-ptr.h as a starting point to write code > that > allocates a 2-page fenced memory region ourselves, then placing the > problematic > string such that the trailing '\0' is the last dereferenceable byte before > the > protected page, so that we can expose the alpha-specific glibc bug in memchr > even without the use of efence.
Sounds good to me. > And with the recent thread of memchr also being broken on x86_64, I'm > starting > to think that we need to do something like this. I don't have access to > either > x86_64 or alpha, so I don't know if this is sufficient to detect the broken > memchr implementations out there; comments are welcome on whether we should > polish and apply this patch. My gnulib autobuilder is a x86_64 system (running Ubuntu 8.04 LTS), so if the test starts to fail, it will show up here in a few hours: http://autobuild.josefsson.org/gnulib/#000-gnulib-simple-gaggia /Simon
