4:41 a.m.
I'm not sure if this is a GCC bug or a bug in our code, but
the attached workaround fixes it for me.
Rich.
4:41 a.m.
Previously with GCC 10.2 this code produced:
In function ‘nbdkit_strndup_intern’,
inlined from ‘nbdkit_strdup_intern’ at public.c:839:10:
public.c:827:10: error: ‘strndup’ specified bound 18446744073709551615 exceeds maximum
object size 9223372036854775807 [-Werror=stringop-overflow=]
827 | copy = strndup (str, n);
| ^~~~~~~~~~~~~~~~
---
server/public.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/server/public.c b/server/public.c
index e871fdeb..270f81a4 100644
--- a/server/public.c
+++ b/server/public.c
@@ -836,7 +836,21 @@ nbdkit_strndup_intern (const char *str, size_t n)
const char *
nbdkit_strdup_intern (const char *str)
{
- return nbdkit_strndup_intern (str, SIZE_MAX);
+ char *copy;
+
+ if (str == NULL) {
+ nbdkit_error ("nbdkit_strdup_intern: no string given");
+ errno = EINVAL;
+ return NULL;
+ }
+
+ copy = strdup (str);
+ if (copy == NULL) {
+ nbdkit_error ("strdup: %m");
+ return NULL;
+ }
+
+ return add_intern (copy);
}
const char *
--
2.27.0
8:54 a.m.
On 9/3/20 4:41 AM, Richard W.M. Jones wrote:
Previously with GCC 10.2 this code produced:
In function ‘nbdkit_strndup_intern’,
inlined from ‘nbdkit_strdup_intern’ at public.c:839:10:
public.c:827:10: error: ‘strndup’ specified bound 18446744073709551615 exceeds maximum
object size 9223372036854775807 [-Werror=stringop-overflow=]
827 | copy = strndup (str, n);
| ^~~~~~~~~~~~~~~~
---
server/public.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
I find the gcc warning annoying, but this workaround is fine (and
potentially even a bit more efficient, because it uses fewer function
calls).
ACK, regardless of whether gcc also agrees with your bug report.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
8:55 a.m.
On Thu, Sep 03, 2020 at 08:54:08AM -0500, Eric Blake wrote:
On 9/3/20 4:41 AM, Richard W.M. Jones wrote:
>Previously with GCC 10.2 this code produced:
>
>In function ‘nbdkit_strndup_intern’,
> inlined from ‘nbdkit_strdup_intern’ at public.c:839:10:
>public.c:827:10: error: ‘strndup’ specified bound 18446744073709551615 exceeds
maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
> 827 | copy = strndup (str, n);
> | ^~~~~~~~~~~~~~~~
>---
> server/public.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
I find the gcc warning annoying, but this workaround is fine (and
potentially even a bit more efficient, because it uses fewer
function calls).
ACK, regardless of whether gcc also agrees with your bug report.
Nope they didn't :-(
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
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
4:47 a.m.
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 ...
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
4:51 a.m.
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 :|
4:59 a.m.
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
8:58 a.m.
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
1465
days inactive
1465
days old
7 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
Eric Blake -
Richard W.M. Jones