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

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 23/3/23 20:00, Daniel P. Berrangé 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.


> IMHO the status quo is bad because it is actively dangerous when
> combined with goto and we aren't using any compiler warnings to
> help us.

Thanks, TIL this, interesting.

> Either we allow it, but use -Wjump-misses-init to prevent mixing
> delayed declarations with gotos, and just avoid this when it triggers
> a false positive.
> 
> Or we forbid it, rewrite current cases that use it, and then add
> -Wdeclaration-after-statement to enforce it.

I guess various macros (Q/LIST/FOO_FOREACH_BAR i.e.) already abuse that.

> 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.
But we need to be aware of:

      With the option '-ftrivial-auto-var-init', all the automatic
      variables that do not have explicit initializers will be
      initialized by the compiler.  These additional compiler
      initializations might incur run-time overhead, sometimes
      dramatically.

Also:

     ‘pattern’ Initialize automatic variables with values which will
     likely transform logic bugs into crashes down the line, are easily
     recognized in a crash dump and without being values that programmers
     can rely on for useful program semantics. The current value is
     byte-repeatable pattern with byte "0xFE". The values used for
     pattern initialization might be changed in the future.

If we use -ftrivial-auto-var-init, could the
-ftrivial-auto-var-init=pattern form could be more beneficial to us?