This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Storage for uninitialized objects (PR 24626)
- From: Paul Schlie <schlie at comcast dot net>
- To: Robert Dewar <dewar at adacore dot com>
- Cc: Ian Lance Taylor <ian at airs dot com>, John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>, <gcc at gcc dot gnu dot org>
- Date: Sun, 15 Jan 2006 05:48:54 -0500
- Subject: Re: Storage for uninitialized objects (PR 24626)
So following through with this philosophy to its natural conclusion,
all programs which contain reachable non-portable undefined code should
have arbitrary behavior? Or should arbitrary potentially catastrophic
otherwise unexpected behavior only be invoked upon reaching such code?
(or might it actually make substantially more sense for a compiler to
do what the code logically specified in absents of any more reliably
predictable alternative; under the premise that consistency is good.)
> From: Robert Dewar <dewar@adacore.com>
>> Paul Schlie wrote:
>> tools which indiscriminately alter non-portable observable
>> behavior during optimization aren't doing anyone any favors.
>>
> What we want from a compiler is that it correctly executes
> and interprets correct programs. What we want from
> programmers is correct programs. Programmers who
> write undefined junk get undefined behavior. We have
> been through this before (with you if I remember), and
> we won't get any further this time than we did last time.
> Uninitialized variables cause undefined behavior. This
> means the behavior of the program can change every
> time you run it (whether or not you change optimization
> settings).