qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Akihiko Odaki <akihiko.odaki@gmail.com>,
	Roman Bolshakov <r.bolshakov@yadro.com>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [RFC PATCH 4/4] ui/cocoa: Ignore 'initializer overrides' warnings
Date: Tue, 15 Feb 2022 14:18:32 +0100	[thread overview]
Message-ID: <5430167.XuPm0vUgvV@silver> (raw)
In-Reply-To: <20220215120625.64711-5-f4bug@amsat.org>

On Dienstag, 15. Februar 2022 13:06:25 CET Philippe Mathieu-Daudé via wrote:
> We globally ignore the 'initializer overrides' warnings in C code
> since commit c1556a812a ("configure: Disable (clang)
> initializer-overrides warnings"). Unfortunately the ${gcc_flags}
> variable is not propagated to Objective-C flags ($OBJCFLAGS).
> Instead of reworking the configure script to test all supported
> C flags in Objective-C and sanitize them, ignore the warning
> locally with the GCC diagnostic #pragma (Clang ignores it).
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---

What about this instead:

diff --git a/ui/cocoa.m b/ui/cocoa.m
index ac18e14ce0..df9b9be999 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -652,9 +652,7 @@ QemuCocoaView *cocoaView;
 
     /* translates Macintosh keycodes to QEMU's keysym */
 
-    int without_control_translation[] = {
-        [0 ... 0xff] = 0,   // invalid key
-
+    int without_control_translation[256] = {
         [kVK_UpArrow]       = QEMU_KEY_UP,
         [kVK_DownArrow]     = QEMU_KEY_DOWN,
         [kVK_RightArrow]    = QEMU_KEY_RIGHT,
@@ -667,9 +665,7 @@ QemuCocoaView *cocoaView;
         [kVK_Delete]        = QEMU_KEY_BACKSPACE,
     };
 
-    int with_control_translation[] = {
-        [0 ... 0xff] = 0,   // invalid key
-
+    int with_control_translation[256] = {
         [kVK_UpArrow]       = QEMU_KEY_CTRL_UP,
         [kVK_DownArrow]     = QEMU_KEY_CTRL_DOWN,
         [kVK_RightArrow]    = QEMU_KEY_CTRL_RIGHT,

That warning should only be raised on overlapping designated initializations
which strictly is undefined behaviour. Because which order defines the
precedence of overlapping initializers, is it the order of the designated
intializer list, or rather the memory order?

See also:
https://stackoverflow.com/questions/40920714/is-full-followed-by-partial-initialization-of-a-subobject-undefined-behavior

So I have my doubts whether this warning suppression should be used in QEMU at
all.

Best regards,
Christian Schoenebeck




  parent reply	other threads:[~2022-02-15 13:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 12:06 [RFC PATCH 0/4] buildsys: More fixes to use GCC on macOS Philippe Mathieu-Daudé via
2022-02-15 12:06 ` [RFC PATCH 1/4] osdep: Avoid using Clang-specific __builtin_available() Philippe Mathieu-Daudé via
2022-02-15 12:06 ` [PATCH 2/4] osdep: Un-inline qemu_thread_jit_execute/write Philippe Mathieu-Daudé via
2022-02-15 13:09   ` Akihiko Odaki
2022-02-15 13:29     ` Philippe Mathieu-Daudé via
2022-02-15 12:06 ` [RFC PATCH 3/4] audio: Rename coreaudio extension to use Objective-C compiler Philippe Mathieu-Daudé via
2022-02-15 13:37   ` Christian Schoenebeck
2022-02-15 12:06 ` [RFC PATCH 4/4] ui/cocoa: Ignore 'initializer overrides' warnings Philippe Mathieu-Daudé via
2022-02-15 12:34   ` Peter Maydell
2022-02-15 13:19     ` Akihiko Odaki
2022-02-15 13:23       ` Philippe Mathieu-Daudé via
2022-02-15 13:18   ` Christian Schoenebeck [this message]
2022-02-15 13:45     ` Peter Maydell
2022-02-15 14:06       ` Philippe Mathieu-Daudé via
2022-02-15 14:11       ` Christian Schoenebeck
2022-02-15 14:17         ` Peter Maydell
2022-02-15 13:06 ` [RFC PATCH 0/4] buildsys: More fixes to use GCC on macOS Akihiko Odaki
2022-02-15 13:25   ` Philippe Mathieu-Daudé via
2022-02-16  2:28     ` Akihiko Odaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5430167.XuPm0vUgvV@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=akihiko.odaki@gmail.com \
    --cc=f4bug@amsat.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=r.bolshakov@yadro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).