Juan Quintela <quint...@redhat.com> writes:
> Daniel P. Berrangé <berra...@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