memchr bug? Request for enlightenment (lowercase 'e')

[<michael donahue nist gov>]

While doing some code testing with Electric Fence, I came across the
following curiosity, on a stock RedHat 6.2/AXP system.

Consider the short test program:

   #include <string.h>
   #include <stdlib.h>

   #define TESTSTRING "12345678"

   int main()
   {
     char *p = (char *)malloc(strlen(TESTSTRING)+1);
     strcpy(p,TESTSTRING);
     memchr(p,'\0',79);
     free(p);
     return 0;
   }

When I compile and run I get

   $ gcc memchr-test.c -lefence
   $ ./a.out

     Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
   Segmentation fault

It appears that memchr is reading memory past the end of the malloc'ed
region.  I don't know if this is actually a problem or not, but I don't
see this behavior on Linux/x86 or Solaris.  Incidentally, I can replace
'\0' above with '5', '6', '7' or '8' with the same results.  OTOH, '4'
is okay, and I see no segfault with strlen().

So, is this a bug?  Has it been fixed in newer libc?

BTW, the *printf family uses memchr in its %.ns conversions, e.g.,
the following code exhibits the same behavior:

   #include <stdio.h>
   #include <string.h>
   #include <stdlib.h>

   #define TESTSTRING "12345678"

   int main()
   {
     char *p = (char *)malloc(strlen(TESTSTRING)+1);
     strcpy(p,TESTSTRING);
     printf("%.79s\n",p);
     free(p);
     return 0;
   }

-m

-- 
Michael J. Donahue
National Institute of Standards and Technology
Mathematical & Computational Sciences Division
100 Bureau Dr Stop 8910
Gaithersburg, MD 20899-8910
email: michael.donahue@nist.gov
voice: (301) 975-5424
  fax: (301) 990-4127
  web: http://math.nist.gov/~MDonahue/