Re: [PATCH] Change the default for Mixed declarations.

["Alex Bennée" <alex.bennee@linaro.org>]

Juan Quintela <quintela@redhat.com> writes:

> Daniel P. Berrangé <berrange@redhat.com> wrote:
>> On Tue, Feb 14, 2023 at 05:07:38PM +0100, Juan Quintela wrote:
>>> Hi
>>> 
>>> I want to enter a discussion about changing the default of the style
>>> guide.
>>> 
>>> There are several reasons for that:
>>> - they exist since C99 (i.e. all supported compilers support them)
>>> - they eliminate the posibility of an unitialized variable.
>>
>> Actually they don't do that reliably. In fact, when combined
>> with usage of 'goto', they introduce uninitialized variables,
>> despite the declaration having an initialization present, and
>> thus actively mislead reviewers into thinking their code is
>> safe.
>
> Wait a minute.
> If you use goto, you are already in special rules.
>
> And don't get confused, I fully agree when using goto for two reasons:
> - performance
>   if you show that the code is x% faster when using goto, it is
>   justified.  It is even better if you send a bug report to gcc/clang,
>   but I will not opose that use.

I await a clear example in the context of QEMU - there is almost always
a better way to structure things.

> - code clearity
>   Some code (basically error paths) are clearer with goto that without
>   them.

Now we have g_auto* and lock guards we should encourage their use. goto
error_path is a relic of a simpler time ;-)

<snip>
>> IMHO if we are concerned about uninitialized variables then I think
>> a better approach is to add -ftrivial-auto-var-init=zero, which will
>> make the compiler initialize all variables to 0 if they lack an
>> explicit initializer. 
>
> I think this is a bad idea.
> If we want to "catch" unitialized variables, using something like:
>
> -ftrivial-auto-var-init=pattern sounds much saner.
>
> Obviously gcc is missing
>
> -ftrivial-auto-var-init=42

I think we could at least eat the runtime cost of
-ftrvial-auto-var-init=0xDEADBEEF for our --enable-debug builds.

>
> But well, no project is perfect.
>
> Later, Juan.


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro