Eric Blake wrote:
> http://www.alphalinux.org/archives/axp-list/March2001/0337.shtml
>
> It looks like the bug is alpha-specific in memchr
I don't think it is a bug. memchr could also be implemented by doing
a backwards search and still be conforming to ISO C99 and POSIX:
void *memchr(const void *s, int c, size_t n)
{
void *found = NULL;
size_t i;
i = n;
while (i > 0)
{
i--;
if (((unsigned char *)s)[i] == (unsigned char) c)
found = &((unsigned char *)s)[i];
}
return found;
}
> in anything else that
> uses memchr to search for a trailing \0 with a length longer than the
> allocated memory
It is such uses of memchr() that are buggy. When you call memchr(s,c,n), you
must guarantee read access for the bytes at s, ..., s+n-1.
> it will manifest itself with gnulib's strstr
Then gnulib's and glibc's strstr is buggy.
> as well as in anything else that uses memchr to search for a trailing \0
> with a length longer than the allocated memory
Yes, this would be buggy as well. strchr or strlen needs to be used instead,
if the amount of allocated memory is unknown.
> In other words, even code like vasnprintf.c is also suspect, because it
> uses memchr(,\0,) under the hood for %.*s.
Yes, I agree this is a bug as well.
Bruno
