[libvirt] [PATCH] qemu: Don't initialize struct utsname

It breaks the build and it is not really useful for anything. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> --- Pushed under the build breaker rule. src/qemu/qemu_capabilities.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 2c573827f1..5e03447baa 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -5431,7 +5431,7 @@ virQEMUCapsCacheNew(const char *libDir, char *capsCacheDir = NULL; virFileCachePtr cache = NULL; virQEMUCapsCachePrivPtr priv = NULL; - struct utsname uts = { 0 }; + struct utsname uts; if (virAsprintf(&capsCacheDir, "%s/capabilities", cacheDir) < 0) goto error; -- 2.16.0

On Mon, Jan 22, 2018 at 02:54:42PM +0100, Jiri Denemark wrote:
It breaks the build and it is not really useful for anything.
Why does that break the build ? "{ 0 }" is a valid initializer for any struct according to the C standards.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> ---
Pushed under the build breaker rule.
src/qemu/qemu_capabilities.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 2c573827f1..5e03447baa 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -5431,7 +5431,7 @@ virQEMUCapsCacheNew(const char *libDir, char *capsCacheDir = NULL; virFileCachePtr cache = NULL; virQEMUCapsCachePrivPtr priv = NULL; - struct utsname uts = { 0 }; + struct utsname uts;
if (virAsprintf(&capsCacheDir, "%s/capabilities", cacheDir) < 0) goto error; -- 2.16.0
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 :|

On Mon, Jan 22, 2018 at 14:01:26 +0000, Daniel P. Berrange wrote:
On Mon, Jan 22, 2018 at 02:54:42PM +0100, Jiri Denemark wrote:
It breaks the build and it is not really useful for anything.
Why does that break the build ? "{ 0 }" is a valid initializer for any struct according to the C standards.
Yeah, it seems -Wmissing-braces falsely reports missing braces in there. It worked just fine on my host, by our Jenkins builders all failed on it. Anyway, I didn't bother looking at details as it's easier to drop the initializer. And doing so makes usage of struct utsname in libvirt consistent. Jirka

On Mon, Jan 22, 2018 at 03:12:46PM +0100, Jiri Denemark wrote:
On Mon, Jan 22, 2018 at 14:01:26 +0000, Daniel P. Berrange wrote:
On Mon, Jan 22, 2018 at 02:54:42PM +0100, Jiri Denemark wrote:
It breaks the build and it is not really useful for anything.
Why does that break the build ? "{ 0 }" is a valid initializer for any struct according to the C standards.
Yeah, it seems -Wmissing-braces falsely reports missing braces in there. It worked just fine on my host, by our Jenkins builders all failed on it. Anyway, I didn't bother looking at details as it's easier to drop the initializer. And doing so makes usage of struct utsname in libvirt consistent.
Looks like it generates the bogus warning when the first field of the struct is itself another struct. eg struct Base { int a; } struct One { int b; struct base c; }; struct Two { struct base c; int b; }; struct One one = {0}; struct Two two = {0}; The 'two' initializer generates a warning but the 'one' initializer does not. So that explains why most of our {0} initalizers are working ok at least. 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 :|
participants (2)
-
Daniel P. Berrange
-
Jiri Denemark