On Mon, May 16, 2022 at 07:23:20AM -0700, John Reiser wrote: > On 5/11/22 19:35, Steve Grubb wrote: > > On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote: > [snip] > > > Fast-forward a few months and I see GCC 12.1 is released now with > > > -ftrivial-auto-var-init option support [2]. > > > > > > Are you going to take this idea forward and make a formal change proposal > > > for Fedora to set -ftrivial-auto-var-init=zero by default in its default > > > RPM build flags ? > > > > I've connected with the gcc folks and we will file a proposal in the near > > future. > > Zero is the worst possible auto-int value. It will hide the most bugs. > Zero is unrecognizable as an auto-init value by hardware, code, and humans. I guess it depends on the POV, it effectively turns it into a non-bug in the vast majority of cases. Zero initialized is what the programmer would have intended to use in a large % of the time, and is thus likely to result in safe behaviour. Free'ing zero is a no-op for a pointer. De-referencing a NULL pointer is an immediate crash, and easy to trace backwards from - whether it was an explicit or implicit NULL doesn't really matter. For non-pointer values it is usuaully good, for example as a loop bound it will terminate quickly, for a data size it wouldn't result in huge allocations. The most common case where zero is not good will be for UNIX file descriptors, where -1 is the better value. Still it will be a net win in general IMHO. Static analysis tools and GCC warnings can still be used at the same time as the automatic zero-init, so maintainers can still get warned about as many of the problemas the tools are able to identify. The remaining cases are made safer by the auto zero init, and often eliminating the crash entirely which is good for users too. > The auto-init value should be recognizable instantly in all circumstances. > The value which comes to mind is 0x81 in every byte. This is the "core constant" > used by the Michigan Terminal System beginning 1967 (yes, 55 years ago!) > on IBM S/360-67 and S/370 hardware; see https://en.wikipedia.org/wiki/MTS_system_architecture. > > As a signed integer the value is negative, which trips assumptions of "positive or zero" > for loop counters or array indices. As a virtual address, (void *)0x818181..81 > triggers a fault, thus catching uninit pointers. 0x81 stands out in a hex dump. > Programmers quickly learn the 32-bit integer value "-2122219135". > > Please do not use zero as the default auto-init value. Use 0x818181..81 instead. Using a large value like that is not good for non-pointer variables. It would result in loop iterations burning CPU cycles, or malloc allocations being enourmous, or out of bound array accesses and other bad behaviour. 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 :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
