[cfe-dev] [RFC] automatic variable initialization

[Tim Northover via cfe-dev]

On Mon, 19 Nov 2018 at 23:26, Mehdi AMINI <joker.eph at gmail.com> wrote:
> Le jeu. 15 nov. 2018 à 15:00, Tim Northover via cfe-dev <cfe-dev at lists.llvm.org> a écrit :
>>
>> On Thu, 15 Nov 2018 at 22:53, JF Bastien via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>> >   2. Zero initialization
>> >
>> >     Zero initialize all values. This has the unfortunate side-effect of
>> >     providing semantics to otherwise undefined behavior, programs therefore
>> >     might start to rely on this behavior, and that's sad. However, some
>> >     programmers believe that pattern initialization is too expensive for them,
>> >     and data might show that they're right. The only way to make these
>> >     programmers wrong is to offer zero-initialization as an option, figure out
>> >     where they are right, and optimize the compiler into submission. Until the
>> >     compiler provides acceptable performance for all security-minded code, zero
>> >     initialization is a useful (if blunt) tool.
>>
>> I disagree with this. I think this is essentially defining a new
>> dialect of C++, which I have massive concerns about. Additionally, as
>> much as we might claim it's a transitional measure, we all know that's
>> not how it'll be used in practice.
>
> How is it different that other options like -fno-strict-aliasing or trap on sign integer wrap?
> These are all options that are "defining new dialect of C++", yet are useful for some customers.
> Why is it that bad to support a "new dialect" in these conditions?

IMO, it's *not* very different but we were forced to support those for
compatibility with GCC. I don't think people properly considered the
implications of either of those when adding them. Where possible we've
been trying to educate users and move them to sanitizers so that they
can fix their code.

Also, each additional dialect axis we add makes the problem exponentially worse.

Cheers.

Tim.