This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc3 vs 176.gcc
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Joe Buck <jbuck at synopsys dot COM>
- Cc: Richard Henderson <rth at redhat dot com>, <geoffk at redhat dot com>, <dalej at apple dot com>, <gcc at gcc dot gnu dot org>
- Date: Thu, 10 Jan 2002 23:40:23 +0000 (GMT)
- Subject: Re: gcc3 vs 176.gcc
On Thu, 10 Jan 2002, Joe Buck wrote:
> This is an odd way of looking at things. Consider code that accesses
> a private data member in C++ without permission. Are you saying that
> instead of producing an error, we should produce code that calls abort()
> if the code is reached? It's exactly the same sort of thing: the ISO
> standard forbids the code in either case.
In the C case, the standard forbids the code from being executed; the
undefined behaviour only occurs if certain accesses occur, and "effective
type" is a runtime property. The code
int x;
if (0) *(short *)&x = 1;
is strictly conforming. (And "0" here could be a macro that was
autoconfigured in some way so that it is only nonzero if the aliasing
rules allow the access.)
In the C++ case you give, the standard says the program is ill-formed, and
does not say it yields undefined behaviour. The C++ conformance rules in
this area are different from those for C:
# 1.4 Implementation compliance [intro.compliance]
#
# 1 The set of diagnosable rules consists of all syntactic and semantic
# rules in this International Standard except for those rules containing
# an explicit notation that "no diagnostic is required" or which are
# described as resulting in "undefined behavior."
#
# 2 Although this International Standard states only requirements on C++
# implementations, those requirements are often easier to understand if
# they are phrased as requirements on programs, parts of programs, or
# execution of programs. Such requirements have the following meaning:
#
# - If a program contains no violations of the rules in this International
# Standard, a conforming implementation shall, within its resource limits,
# accept and correctly execute[3] that program.
# - If a program contains a violation of any diagnosable rule, a
# conforming implementation shall issue at least one diagnostic message,
# except that
# - If a program contains a violation of a rule for which no diagnostic is
# required, this International Standard places no requirement on
# implementations with respect to that program.
#
# [3] "Correct execution" can include undefined behavior, depending on the
# data being processed; see 1.3 and 1.9.
The C++ aliasing rules, 3.10 [basic.lval] paragraph 15, again relate only
to when the program attempts an access, not to the present of constructs
such as the above in the source code.
--
Joseph S. Myers
jsm28@cam.ac.uk