This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]