This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: type based aliasing again
- To: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Subject: Re: type based aliasing again
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Tue, 14 Sep 1999 19:13:08 -0400
- Cc: Mark Mitchell <mark at codesourcery dot com>, craig at jcb-sc dot com, nik at tiuk dot ti dot com, richard dot earnshaw at arm dot com, N8TM at aol dot com, gcc at gcc dot gnu dot org, espie at quatramaran dot ens dot fr
>>>>> Toon Moene writes:
Toon> I do not deny that there are programmers who _think_ that that sort of
Toon> type-mixing pointing is "allowed" - we can all count the "bug reports"
Toon> we get because they do.
As far as I can tell, the C standard allowed it to the extent that
its behavior was undefined. It was not disallowed and was left to the
implementation what result it produced. Most compilers, including GCC,
have been producing a reasonable result under most circumstances when
faced with this construct. I think that RMS's interpretation is that if
the limitations of a processor or system made this difficult or
impossible, a compiler writer could defend the lack of functionality by
saying the standard leaves the bahavior undefined.
When the compiler and architecture allow this construct to produce
reasonable results and other compilers produce reasonable results and GCC
still can produce reasonable results more often when an optional
optmization is not applied, then why not allow tihs construct to work
unless the user specifically request more aggressive optimization?
David