Behavior of a program that violates a constraint

[Keith Thompson]

The standard requires an implementation to produce a diagnostic for
any translation unit that violates a constraint or syntax error.
N1370 5.1.1.3p1:

A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as undefined
or implementation-defined.

But this doens't require the implementation to *reject* the
translation unit; it can do so, or it can issue a warning and then
go ahead and generate a working executable. (gcc, for example,
does this in a lot of cases.)

The behavior of such an executable is undefined.

My question is, is the behavior undefined by omission, or am I
missing some normative wording in the standard that says explicitly
that it's undefined? (Or are there cases where the behavior is
*not* undefined?)

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[James Kuyper]

On 11/04/2012 02:20 AM, Keith Thompson wrote:
> The standard requires an implementation to produce a diagnostic for
> any translation unit that violates a constraint or syntax error.
> N1370 5.1.1.3p1:
>
> A conforming implementation shall produce at least one
> diagnostic message (identified in an implementation-defined
> manner) if a preprocessing translation unit or translation
> unit contains a violation of any syntax rule or constraint,
> even if the behavior is also explicitly specified as undefined
> or implementation-defined.
>
> But this doens't require the implementation to *reject* the
> translation unit; it can do so, or it can issue a warning and then
> go ahead and generate a working executable. (gcc, for example,
> does this in a lot of cases.)
>
> The behavior of such an executable is undefined.
>
> My question is, is the behavior undefined by omission, or am I
> missing some normative wording in the standard that says explicitly
> that it's undefined? (Or are there cases where the behavior is
> *not* undefined?)

You posed the same question on comp.std.c in 2007-10-29 in a thread
titled "Does a constraint violation cause undefined behavior?", as a
follow-up to a comp.lang.c thread titled "Is this an error or undefined
behaviour?".
I pointed out to you at the time that you had asked the same question in
the same forum on 2006-04-26 with the title "Does a constraint violation
imply undefined behavior?"
I suppose, with a new version of the standard having been issued, it's
reasonable to re-examine the question.

In the first discussion, people claimed that the definition of
constraints (3.6p1) "restrictions, both syntactic and semantic, by which
the exposition of language elements is to be interpreted" implied that a
program which violates a constraint is not a C program, and therefore no
other requirements imposed by the C standard were applicable. I find the
meaning of the final clause of that definition extremely obscure. I
suggested a re-write that would more clearly support the conclusions
they were reaching: "restrictions, both syntactic and semantic, which
must be satisfied in order for the exposition of language elements given
in this standard to be meaningful.". No one even commented on that
suggestion, and n1570.pdf contains the same wording, though it's now 3.8p1.

During the second discussion, I surveyed the constraints mentioned in
the standard, and came to the conclusion that, in most cases, the
behavior was undefined by omission - with one exception: application of
++ or -- to an lvalue of complex type. You suggested that this was only
accidental, and I agreed that your suggestion was plausible.

In the course of that discussion, I cited 5.1.1.3p1 from N1256.pdf. It's
been re-worded for N1570.pdf, but the key features have not been changed:

> A conforming implementation shall produce at least one diagnostic message (identified in
> an implementation-defined manner) if a preprocessing translation unit or translation unit
> contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
> specified as undefined or implementation-defined.

That implies that there may be cases where "violation of a syntax rule
or a constraint" might NOT have "behavior [which] is also explicitly
specified as undefined". In particular, it directly implies that there
might be cases where it's merely implementation-defined - otherwise the
final "or" clause would have been redundant.
--
James Kuyper