Re: Integer overflows in memchr

[Po Lu]

Bruno Haible <bruno@clisp.org> writes:

> When the text says "the array S of size MAXLEN", it means that the bytes
> S[0], S[1], ..., S[MAXLEN-1] must be accessible. Which is not the case if
> you pass MAXLEN as > ~(uintptr_t)S.
>
> The implementation could, for example, examine
>   S[0], S[MAXLEN-1], S[1], S[MAXLEN-2], ...
> in this order and thus achieve the "more efficient" statement.

Then the libc documentation is self-contradictory, because this is not
even remotely equivalent to (strlen (S) < MAXLEN ? strlen (S) : MAXLEN),
not to mention inconsistent with established usage, in Emacs no less
than in Gnulib and glibc themselves.  lib/fnmatch.c:

int
fnmatch (const char *pattern, const char *string, int flags)
{
  if (__glibc_unlikely (MB_CUR_MAX != 1))
    {
      mbstate_t ps;
      size_t n;
      const char *p;
      WCHAR_T *wpattern_malloc = NULL;
      WCHAR_T *wpattern;
      WCHAR_T *wstring_malloc = NULL;
      WCHAR_T *wstring;
      size_t alloca_used = 0;

      /* Convert the strings into wide characters.  */
      memset (&ps, '\0', sizeof (ps));
      p = pattern;
      n = strnlen (pattern, 1024);

What guarantees that all 1024 bytes subsequent to PATTERN will be
accessible?