Re: [RFC PATCH 4/4] ui/cocoa: Ignore 'initializer overrides' warnings

[Peter Maydell]

On Tue, 15 Feb 2022 at 14:11, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
>
> On Dienstag, 15. Februar 2022 14:45:00 CET Peter Maydell wrote:
> > I think this won't zero-initialize, because this is a function
> > level variable, not a global or static, but maybe ObjectiveC
> > rules differ from C here? (Besides, it really should be
> > a static const array.) That said...
>
> That's a base requirement for designated initializers to fallback to automatic
> default initialization (zero) for omitted members. It's like:
>
>         int a[10] = { }; // all zero

Ah, yes, you're right.

> Yes, but if you suppress this warning globally, you shut up the potential
> warning for the linked case as well. And as demonstrated there, you would end
> up with different/unexpected behaviour depending on the precise compiler being
> used.
>
> So I still think it is not a good idea to suppress this warning globally.

We *must* suppress it globally, because we make wide use of the
array-range-initializer idiom that it incorrectly complains about,
and we don't want to discourage use of that. This is fairly standard
for compiler warnings: sometimes the compiler complains too much,
or the intent of the warning is something we disagree with. Those
warnings we disable or don't enable. In this particular case, if the
compilers ever develop versions of this warning that complain about
actual bugs without also warning about false positives like this
one, we could turn the warning on again.

Put another way, there's a tradeoff here. Sometimes it's worth
distorting the way we would write code to avoid compiler warnings,
because we'd like to keep them enabled to catch some real bugs.
Sometimes the distortion would be too much, and then we take the
choice to disable the warning. There's a judgement call based on
how much perfectly-fine code the compiler is warning about and
how much worse the rewritten code would be. In the case of this
warning we've decided that the tradeoff favours disabling the warning.

Having made that decision on a codebase-wide basis, we should then
just adhere to it whether we're building ObjC or C.

thanks
-- PMM