On Mon, Jul 27, 2026 at 02:25:39PM +0900, Akihiko Odaki wrote: > On 2026/07/27 6:07, Marc-André Lureau wrote: > > Hi > > > > On Mon, Jul 27, 2026 at 12:53 AM Michael S. Tsirkin <[email protected]> wrote: > > > > > > On Mon, Jul 27, 2026 at 12:44:06AM +0400, Marc-André Lureau wrote: > > > > When compiled with -Og, gcc produces many false-positives > > > > gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2). > > > > > > it hurts if you do it? so don't do it then? > > > > We are not far from getting it working, we can accommodate a bit of > > code while making it a bit clearer for the reader too. > > > > > > > > > We already use auto-var-init=zero, but better be explicit. > > > > > > explicit about false positives? > > > > Explicit initialization > > These are the same concerns I raised in my previous review: > > https://lore.kernel.org/qemu-devel/[email protected]/ > > I do not think this patch make the code clearer. They add values that are > never consumed, which obscures rather than clarifies the data flow. Leaving > a variable uninitialized until its actual value is assigned makes that flow > more explicit.
We've seen time & again that human reviewers fail to reliably identify when variables are initialized vs uninitialized, leading to countless CVEs over the years. We want everything initialized to reduce our security risk profile. We added auto-var-init=zero as a backstop to have implicit initialization on the basis that zero-init is the right thing to do 95% of the time. None the less, we should be adding explicit initialization to everywhere so that we're clear about when we want zero vs non-zero initialization, plus a few places we explicitly mark & disable initialization for performance reasons. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
