[cfe-dev] [RFC] automatic variable initialization

[Richard Smith via cfe-dev]

On Tue, 27 Nov 2018 at 11:52, Kostya Serebryany via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Tue, Nov 27, 2018 at 10:43 AM Sean McBride <sean at rogue-research.com>
> wrote:
>
>> On Tue, 27 Nov 2018 10:19:03 -0800, Kostya Serebryany via cfe-dev said:
>>
>> >One more data point: among the bugs found by MSAN in Chrome over the past
>> >few years 449 were uninitialized heap and 295 were uninitialized stack.
>> >So, the proposed functionality would prevent ~40% (i.e. quite a bit!) of
>> >all UUMs in software like Chrome.
>>
>> I just lurk here, but I think the proposed functionality would be greatly
>> appreciated by C/C++/Obj-C developers on macOS, where MemorySanitizer is
>> not supported and valgrind can't even launch TextEdit.  If I'm not
>> mistaken, it would be the *only* tool on macOS to catch UUMs.
>>
>
> It won't catch anything -- but it will prevent the stack UUMs from hurting
> you in production.
>

Well, it will prevent them from resulting in unbounded UB, yes, but that's
not the only thing that hurts you.

A few years back I improved clang's -Wuninitialized and it found a few
hundred bugs in one codebase. Of those, in only about half of the cases was
the correct fix to zero-initialize; the uninitialized read was very often
symptomatic of a logic bug in the function. Now suppose a compiler adds a
flag to automatically zero-initialize. This will likely catch on, just like
-fno-strict-aliasing did, because it makes it easier to write wrong code
that appears to work, and there's a tendency to value code appearing to
work more than you value it actually working. And before you know it, ~all
large projects need to be built with that flag enabled all the time,
because they depend on some code that expects uninitialized variables to be
zero-initialized (say, in inline functions or templates). Now we lose an
opportunity to catch lots of bugs (either at compile time or runtime), and
the benefit is that we define away a similar number of bugs. I don't think
it's clear that that's a good tradeoff.

Also, as others have noted, adding an "initialize to zero" flag will create
an incompatible language dialect, just like -fno-strict-aliasing and
-fno-exceptions and -fwrapv (etc) did. We have a general policy that we
don't want to do that. Initializing to a pseudo-random or
intentionally-chosen-to-often-trap bit-pattern seems fine to me, though,
and an entirely reasonable security measure.

Half-baked idea: what if we made it possible to enable a "zero-initialize
all uninitialized variables" mode internally within the compiler but didn't
expose it at all? (That way, you could turn this feature on with a compiler
plugin, but a stock clang binary can't do it no matter what you write on
the command line, unless you have such a plugin, which we don't ship with
clang.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181127/ce8c5184/attachment.html>