bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests/test-strstr.c: Add another self-test.


From: Bruno Haible
Subject: Re: [PATCH] tests/test-strstr.c: Add another self-test.
Date: Wed, 27 May 2009 00:05:07 +0200
User-agent: KMail/1.9.9

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]