scsi: Address spurious clang warning

Some versions of Clang prior to 6.0 (and some builds of clang after, such as 6.0.1-2.fc28) fail to recognize { 0 } as a valid initializer for a struct with subobjects when -Wmissing-braces is enabled.

https://bugs.llvm.org/show_bug.cgi?id=21689 and
https://reviews.llvm.org/rL314499 suggests this should be fixed in 6.0, but it might not be the case for older versions or downstream versions.

For now, follow the precedent of ebf2a499 and replace the standard { 0 } with the accepted { } to silence this warning and allow the build to work under clang 6.0.1-2.fc28, and builds prior to 6.0.

Signed-off-by John Snow <[email protected]>

---

What I am actually less clear on is why this appears to be a problem only now; since the introduction of { 0 } was in 2.11. It might be a regression only in the fedora distribution of Clang 6.0.

Quoted 12 lines · John Snow

Some versions of Clang prior to 6.0 (and some builds of clang after, such as 6.0.1-2.fc28) fail to recognize { 0 } as a valid initializer for a struct with subobjects when -Wmissing-braces is enabled.

https://bugs.llvm.org/show_bug.cgi?id=21689 and
https://reviews.llvm.org/rL314499 suggests this should be fixed in 6.0, but it might not be the case for older versions or downstream versions.

For now, follow the precedent of ebf2a499 and replace the standard { 0 } with the accepted { } to silence this warning and allow the build to work under clang 6.0.1-2.fc28, and builds prior to 6.0.

Quoted 2 lines

Signed-off-by John Snow <[email protected]>

Reviewed-by Eric Blake <[email protected]>

I'm okay if this goes into -rc3 as a build-fix; I'm also okay if it slips to 4.0.

Quoted 5 lines

---

What I am actually less clear on is why this appears to be a problem only now; since the introduction of { 0 } was in 2.11. It might be a regression only in the fedora distribution of Clang 6.0.

Or even a redefinition of struct dm_ioctl in some header where you are just now picking up a new struct layout that tickles the Clang issue in relation to the previous layout (since it is possible to have two structs that are ABI-compatible but where only one of the two has a nested substruct).

scsi/qemu-pr-helper.c static void dm_init(void) · line 239

Quoted 7 lines

+++ b/scsi/qemu-pr-helper.c

scsi/qemu-pr-helper.c +1 -1

@@ -236,7 +236,7 @@ static void dm_init(void)
          perror("Cannot open " CONTROL_PATH);
          exit(1);
      }
-    struct dm_ioctl dm = { 0 };
+    struct dm_ioctl dm = { };

Random thought: would it be worth having "qemu/compiler.h" define a macro:

#if ...broken clang
#define ZERO_INIT {}
#else
#define ZERO_INIT {0}
#endif

and then rewrite all our '= { 0? }' initializers into '= ZERO_INIT'? Or is that aesthetically too ugly?

Quoted 8 lines · John Snow

Some versions of Clang prior to 6.0 (and some builds of clang after, such as 6.0.1-2.fc28) fail to recognize { 0 } as a valid initializer for a struct with subobjects when -Wmissing-braces is enabled.

https://bugs.llvm.org/show_bug.cgi?id=21689 and
https://reviews.llvm.org/rL314499 suggests this should be fixed in 6.0, but it might not be the case for older versions or downstream versions.

Quoted 6 lines

For now, follow the precedent of ebf2a499 and replace the standard { 0 } with the accepted { } to silence this warning and allow the build to work under clang 6.0.1-2.fc28, and builds prior to 6.0.

Signed-off-by John Snow <[email protected]>

Reviewed-by Eric Blake <[email protected]>

I'm okay if this goes into -rc3 as a build-fix; I'm also okay if it slips to 4.0.

Quoted 5 lines

---

What I am actually less clear on is why this appears to be a problem only now; since the introduction of { 0 } was in 2.11. It might be a regression only in the fedora distribution of Clang 6.0.

Or even a redefinition of struct dm_ioctl in some header where you are just now picking up a new struct layout that tickles the Clang issue in relation to the previous layout (since it is possible to have two structs that are ABI-compatible but where only one of the two has a nested substruct).

scsi/qemu-pr-helper.c static void dm_init(void) · line 239

Quoted 7 lines

+++ b/scsi/qemu-pr-helper.c

scsi/qemu-pr-helper.c +1 -1

@@ -236,7 +236,7 @@ static void dm_init(void)
           perror("Cannot open " CONTROL_PATH);
           exit(1);
       }
-    struct dm_ioctl dm = { 0 };
+    struct dm_ioctl dm = { };

Random thought: would it be worth having "qemu/compiler.h" define a macro:

#if ...broken clang
#define ZERO_INIT {}
#else
#define ZERO_INIT {0}
#endif

and then rewrite all our '= { 0? }' initializers into '= ZERO_INIT'?  Or is that aesthetically too ugly?

Some versions of Clang prior to 6.0 (and some builds of clang after, such as 6.0.1-2.fc28) fail to recognize { 0 } as a valid initializer for a struct with subobjects when -Wmissing-braces is enabled.

https://bugs.llvm.org/show_bug.cgi?id=21689 and
https://reviews.llvm.org/rL314499 suggests this should be fixed in 6.0, but it might not be the case for older versions or downstream versions.

For now, follow the precedent of ebf2a499 and replace the standard { 0 } with the accepted { } to silence this warning and allow the build to work under clang 6.0.1-2.fc28, and builds prior to 6.0.

Signed-off-by John Snow <[email protected]>