On Sat, Jan 22, 2022 at 12:36:01PM +0100, Vitaly Zaitsev via devel wrote: > On 21/01/2022 19:04, Steve Grubb wrote: > >Uninitialized variables are a big problem. > > Yes, but as a package maintainer, I don't want to deal with dozens > of crashes after this change. > > Such problems must be fixed by upstream developers, not by > volunteers [package maintainers]. > > Most upstreams will close such bug reports with "Fedora specific > issue" reason, as it was with GLIB assertions. I've manually fixed > many of them in my packages. I'm curious here how you think programs could crash with the proposed changes. For auto (ie stack allocated) variables, as far as any program is concerned this isn't a change at all - after all, an uninitialized stack variable could start off zero as easily as any other value. However I could see there might possibly be a problem with large stack frames (eg. ones containing multi-page buffers). These would now be written to, rather than left untouched. So stack canaries and guard pages might be touched rather than ignored. I think this would highlight an actual bug in the program. In all the C programs I'm involved in we have long added GCC warning flags to limit frame sizes and prohibit VLAs, just because you can never really be sure how big the stack is. There is a concern, I think, with the proposed "always calloc" change, since that would change both the performance and more critically the allocation pattern of the program. A program that mallocs a huge amount of RAM -- assuming vm.overcommit_memory has been changed from its default (eg. 0 -> 1) -- would suddenly begin allocating memory. And generally programs would run a little slower, and some a lot slower. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html _______________________________________________ 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
