On Fri, Mar 24, 2023 at 05:56:46PM +0000, Alex Bennée wrote: > > 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.
If there is ever a case where an uninitialized var gets used as a loop counter, that's 3,735,928,559 iterations. A small value pattern would avoid such CPU burn. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
