[cfe-dev] [RFC] automatic variable initialization

[Troy Johnson via cfe-dev]

Ø  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?


Ø  Also, we forgot to mention the biggest one: `-fno-exceptions`. Despite being very valuable to some users (including myself), it is .. extremely painful to have this divergence.

Yes, new dialects are bad and, yes, exceptions are the worst.  Herb Sutter explains this in tremendous detail in his C++ proposal for replacing exceptions:  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

-Troy

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Chandler Carruth via cfe-dev
Sent: Tuesday, November 20, 2018 5:29 AM
To: Tim Northover <t.p.northover at gmail.com>
Cc: cfe-dev at lists.llvm.org Developers <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [RFC] automatic variable initialization

On Tue, Nov 20, 2018 at 2:21 AM Tim Northover via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
On Mon, 19 Nov 2018 at 23:26, Mehdi AMINI <joker.eph at gmail.com<mailto:joker.eph at gmail.com>> wrote:
> Le jeu. 15 nov. 2018 à 15:00, Tim Northover via cfe-dev <cfe-dev at lists.llvm.org<mailto: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<mailto: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.

FWIW, I think there are other distinctions:

1) The strict aliasing difference is *much* smaller IMO, and in practice causes fewer issues. This may be happenstance because we relatively rarely optimize based on this, but the fact remains that I think this divergence will be much more rapid and significant.

2) I think wrapping math is relatively rarely *depended* on, and quite easy to fix by casting to unsigned.

On the flip side, I think automatic initialization is a much more slippery and steeper slope.

But perhaps the biggest issue is what Tim mentions at the end -- more dialects makes this worse, so the existence of initial dialects doesn't seem to argue for more being OK.


Also, we forgot to mention the biggest one: `-fno-exceptions`. Despite being very valuable to some users (including myself), it is .. extremely painful to have this divergence.

-Chandler



Cheers.

Tim.
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181120/4308d637/attachment.html>