[cfe-dev] [RFC] automatic variable initialization

[Chandler Carruth via cfe-dev]

On Tue, Nov 20, 2018 at 2:21 AM Tim Northover via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
>

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
> 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/8ea35acf/attachment.html>