Libguestfs - Sep 2020 - Re: [PATCH nbdkit] server/public.c: Uninline nbdkit_strdup_intern to avoid compiler warning.

On Thu, Sep 03, 2020 at 10:47:13AM +0100, Richard W.M. Jones
wrote:
> 
> A simple reproducer is:
> 
> ----------------------------------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
> #include <string.h>
> 
> const char *
> copyn (const char *str, size_t n)
> {
>   return strndup (str, n);
> }
> 
> const char *
> copy (const char *str)
> {
>   return copyn (str, SIZE_MAX);
> }
> ----------------------------------------------------------------------
> 
> $ gcc -O2 -Wall -c test.c
> In function ‘copyn’,
>     inlined from ‘copy’ at test.c:15:10:
> test.c:9:10: warning: ‘strndup’ specified bound 18446744073709551615
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
>     9 |   return strndup (str, n);
>       |          ^~~~~~~~~~~~~~~~
> 
> $ gcc --version
> gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3)
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> I'm still not clear if this is a GCC problem or a code problem,
> although Dan pointed out on the list that SIZE_MAX is the largest
> size_t, so I guess our code seems OK ...
The error message seems to indicate that the compiler believes a pointer
cannot reference an object larger than SSIZE_MAX and thus doesn't like
the use of SIZE_MAX.

This is quite strange though, given that malloc() and other C functions
pretty much all use  size_t for object sizes, not ssize_t.

I think we should try reporting to the GCC maintainers for an opinion
on whether its a compiler bug or not

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Filed upstream as:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96916

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

On 9/3/20 4:59 AM, Richard W.M. Jones wrote:
> 
> Filed upstream as:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96916
I just read the response - gcc has a valid point that not all 
implementations optimize strndup() to malloc() only strnlen() bytes, but 
may attempt to allocate the full size bytes.  And malloc(SIZE_MAX) is 
going to fail.  So we _should_ fix our code: even though it happened to 
work on glibc, it is not portable to POSIX

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org