string: Fix GCC 11 `-Werror=stringop-overread' error

  Fix a compilation error:

In function '__rawmemchr',
    inlined from '__rawmemchr' at rawmemchr.c:27:1:
rawmemchr.c:36:12: error: 'memchr' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread]
   36 |     return memchr (s, c, (size_t)-1);
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
../o-iterator.mk:9: recipe for target '.../string/rawmemchr.o' failed

introduced with GCC 11 commit d14c547abd48 ("Add -Wstringop-overread 
for reading past the end by string functions.").
---
 string/rawmemchr.c |    2 ++
 1 file changed, 2 insertions(+)

glibc-stringop-overread.diff
  

* Maciej W. Rozycki via Libc-alpha:

> glibc-stringop-overread.diff
> Index: glibc/string/rawmemchr.c
> ===================================================================
> --- glibc.orig/string/rawmemchr.c
> +++ glibc/string/rawmemchr.c
> @@ -31,6 +31,8 @@ RAWMEMCHR (const void *s, int c)
>    /* GCC 8 warns about the size passed to memchr being larger than
>       PTRDIFF_MAX; the use of SIZE_MAX is deliberate here.  */
>    DIAG_IGNORE_NEEDS_COMMENT (8, "-Wstringop-overflow=");
> +  /* Likewise GCC 11, with a different warning option.  */
> +  DIAG_IGNORE_NEEDS_COMMENT (11, "-Wstringop-overread");
>  #endif

I think this needs to be in its own __GNUC_PREREQ block because GCC 7
does not have -Wstringop-overread.

Thanks,
Florian
  

On Mon, 31 Aug 2020, Florian Weimer wrote:

> > Index: glibc/string/rawmemchr.c
> > ===================================================================
> > --- glibc.orig/string/rawmemchr.c
> > +++ glibc/string/rawmemchr.c
> > @@ -31,6 +31,8 @@ RAWMEMCHR (const void *s, int c)
> >    /* GCC 8 warns about the size passed to memchr being larger than
> >       PTRDIFF_MAX; the use of SIZE_MAX is deliberate here.  */
> >    DIAG_IGNORE_NEEDS_COMMENT (8, "-Wstringop-overflow=");
> > +  /* Likewise GCC 11, with a different warning option.  */
> > +  DIAG_IGNORE_NEEDS_COMMENT (11, "-Wstringop-overread");
> >  #endif
> 
> I think this needs to be in its own __GNUC_PREREQ block because GCC 7
> does not have -Wstringop-overread.

 Umm, I never used this feature before and got confused with the version 
mismatch (7 vs 8) right above:

#if __GNUC_PREREQ (7, 0)
  DIAG_IGNORE_NEEDS_COMMENT (8, "-Wstringop-overflow=");
#endif

misleading me into thinking GCC 7 is the version that introduced the 
`_Pragma' feature we use here.

 Joseph: has the mismatch been intentional?

 I have posted v2 now.

  Maciej
  

On Mon, 31 Aug 2020, Maciej W. Rozycki via Libc-alpha wrote:

>  Umm, I never used this feature before and got confused with the version 
> mismatch (7 vs 8) right above:
> 
> #if __GNUC_PREREQ (7, 0)
>   DIAG_IGNORE_NEEDS_COMMENT (8, "-Wstringop-overflow=");
> #endif
> 
> misleading me into thinking GCC 7 is the version that introduced the 
> `_Pragma' feature we use here.
> 
>  Joseph: has the mismatch been intentional?

All GCC versions supported for building glibc support the relevant pragma.  
However, the pragma gives an error if the -W option named isn't supported 
in the GCC version being used, so __GNUC_PREREQ conditionals are needed 
around uses of the pragma with options not present in the minimum GCC 
version for building glibc (currently GCC 6).

The version number in the macro call is ignored by the macro and is only 
for human readers.  It indicates the *most recent* GCC version with which 
the warning has been observed, and is intended as a hint that a particular 
use of the pragma might be obsolete, if the version named is older than 
the oldest GCC version still supported for building glibc - but actually 
determining whether it is obsolete would require removing the pragma and 
trying building with that GCC version.

That number is more relevant where the pragma is working around a GCC bug, 
and thus might well not be needed with newer GCC, than where the code 
(typically a testcase) is deliberately doing something that is 
deliberately warned about (which is common for tests of various corner 
cases) and thus the warning is not expected to disappear with newer GCC.