Discussion:
[libvirt] [PATCH] util: Fix build on s390
(too old to reply)
Eric Blake
2016-10-13 13:36:54 UTC
Permalink
Raw Message
GCC on s390 complains
util/virconf.c:1220:9: error: format '%zu' expects argument of type
'size_t', but argument 9 has type 'unsigned int' [-Werror=format=]
That's a bug in s390's system headers. Gnulib should be taught to work
around it.
---
src/util/virconf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virconf.c b/src/util/virconf.c
index 3e49f41..1372389 100644
--- a/src/util/virconf.c
+++ b/src/util/virconf.c
@@ -1219,7 +1219,7 @@ int virConfGetValueSizeT(virConfPtr conf,
if (((unsigned long long)cval->l) > SIZE_MAX) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("%s: value for '%s' parameter must be in range 0:%zu"),
- conf->filename, setting, SIZE_MAX);
+ conf->filename, setting, (size_t) SIZE_MAX);
return -1;
}
#endif
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Paul Eggert
2016-10-13 18:23:34 UTC
Permalink
Raw Message
Post by Eric Blake
That's a bug in s390's system headers. Gnulib should be taught to work
around it.
Although this bug was reported fixed in glibc 2.20; see

https://sourceware.org/bugzilla/show_bug.cgi?id=16712

the Gnulib manual says the bug is still in glibc 2.24; see
gnulib/doc/posix-headers/stdint.texi. Is the Gnulib manual correct? If
so, why didn't the earlier glibc patch fix the bug?

Anyway, I installed into Gnulib the attached patch, which I hope works
around the bug. I can't easily test this, so please give it a try. And
if you can think of a way to test whether SIZE_MAX has the correct type
on pre-C11 compilers that lack __typeof__, please let me know.
Eric Blake
2016-10-13 18:50:08 UTC
Permalink
Raw Message
Post by Paul Eggert
Post by Eric Blake
That's a bug in s390's system headers. Gnulib should be taught to work
around it.
Although this bug was reported fixed in glibc 2.20; see
https://sourceware.org/bugzilla/show_bug.cgi?id=16712
the Gnulib manual says the bug is still in glibc 2.24; see
gnulib/doc/posix-headers/stdint.texi. Is the Gnulib manual correct? If
so, why didn't the earlier glibc patch fix the bug?
Anyway, I installed into Gnulib the attached patch, which I hope works
around the bug. I can't easily test this, so please give it a try. And
if you can think of a way to test whether SIZE_MAX has the correct type
on pre-C11 compilers that lack __typeof__, please let me know.
With gcc, -Werror=format flags a mismatch on printf("%zu",SIZE_MAX).

With C++, you can check whether a correct overloaded function is called.

But I don't have any off-hand way of testing it without using compiler
extensions or a different language.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Eric Blake
2016-10-13 19:14:47 UTC
Permalink
Raw Message
Post by Eric Blake
Post by Paul Eggert
Post by Eric Blake
That's a bug in s390's system headers. Gnulib should be taught to work
around it.
Although this bug was reported fixed in glibc 2.20; see
https://sourceware.org/bugzilla/show_bug.cgi?id=16712
the Gnulib manual says the bug is still in glibc 2.24; see
gnulib/doc/posix-headers/stdint.texi. Is the Gnulib manual correct? If
so, why didn't the earlier glibc patch fix the bug?
Anyway, I installed into Gnulib the attached patch, which I hope works
around the bug. I can't easily test this, so please give it a try. And
if you can think of a way to test whether SIZE_MAX has the correct type
on pre-C11 compilers that lack __typeof__, please let me know.
With gcc, -Werror=format flags a mismatch on printf("%zu",SIZE_MAX).
With C++, you can check whether a correct overloaded function is called.
But I don't have any off-hand way of testing it without using compiler
extensions or a different language.
That said, I think a configure test based on -Werror=format would be
sufficient - after all, our objective is only to fix the problem if it
can be observed. If a platform is using pre-C11 gcc and the problem is
observable, we want it fixed; if they are using some other compiler,
then chances are -Wformat does not work, therefore the problem cannot be
portably observed so there is nothing to work around, whether or not the
problem is present. That's the beauty of testing features rather than
compiler versions :)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Paul Eggert
2016-10-13 21:13:53 UTC
Permalink
Raw Message
Post by Eric Blake
I think a configure test based on -Werror=format would be
sufficient
What we have now should work for GCC 2.0 and later, whereas
-Werror=format is a much-newer GCC feature and so would be less portable.
Post by Eric Blake
if they are using some other compiler,
then chances are -Wformat does not work, therefore the problem cannot be
portably observed so there is nothing to work around
I am worried that other compilers might warn about it even without
-Werror=format. (I'm not worried about GCC, as nobody uses GCC 1 any more.)
Loading...