int pointing to char

[James Hu]

I generally ignore freestanding environments, as you could raise
the objection "it may be valid in a f.e." to just about anything
posted on c.l.c.
FWIW, void main() may be valid in a hosted environment too.

Yikes. I didn't really mean ignore (my original response to the OP
did not ignore it). I meant I generally discount it as a source of
erroneous behavior.

-- James

 

[Dan Pop]

[snip]
I don't believe a constraint violation results in undefined behavior,
but IANACLL (xref: 6.5.16.1p1 and 4p1).

I should qualify that with "c.v. doesn't necessarily result in u'd.b.".
[snip]
Like I said, IANACLL, but my understanding was that the behavior of a
constraint violation is unspecified behavior, not undefined behavior.

Since I have only be looking at the assignment operator, this statement
should be restricted to the assignment in question:

char c = 'a';
int *p = &c;

The C standard doesn't classify constraint violations in several
categories. ALL of them have the same effect: a diagnostic is required
after which there are no more requirements from the implementation.
An implementation aborting the translation process after issuing a
required diagnostic would be perfectly conforming.

I think this is true of C89. But, C99 seems to have changed things.

Nope, C99 hasn't changed anything here. ALL constraint violations are
treated identically by C99, as well.

For one thing:

xref 4p2: If a "shall" or "shall not" requirement that appears
outside of a constraint is violated, the behavior is undefined.

And this sentence is repeated in the Appendix the summarizes
undefined behaviors. If a constraint violation implied undefined
behavior, I believe the standard would not have bothered to state
this exception.

Please engage your brain. Undefined behaviour as such does NOT require
a diagnostic. Hence the distinction: violating a shall inside a
constraint requires a diagnostic, violating a shall outside a constraint
doesn't.

The standard stil doesn't provide any clue about the behaviour of a
program violating a constraint, unless you can prove otherwise.

As to the particular assignment, there is a curious example in the
standard:

xref 6.5.16.1p6: EXAMPLE3: Consider the fragment:

const char **cpp;
char *p;
const char c = 'A';

cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 0; // valid

The first assignment is unsafe because it would allow the
following valid code to attempt to change the value of the
const object c.

It seems the standard is implying the statement with the constraint
violation still has valid semantics.

That would be the case if the text said "because it allows the following".
As it is, the standard explains the semantics if the statement in question
were allowed by the language.

The standard explains why the statement is not actually allowed in
correct C programs. A compiler is not required to translate such code,
which wouldn't be the case if the code had valid semantics.

Dan

 

[Dan Pop]

This sentence seems to imply that constraint violations
are all UB (otherwise, I fail to understand your use of 'mere')

AFTER the reqired diagnostic is produced. Big difference!

I agree totally, but the case in point (pointer to int being made to
point to a char) is not in your list of acceptable pointings.

I was addressing your sweeping generalisation underlined above,
that has precious little to do with the case in point. However, even the
case in point is perfectly OK on implementations where all types have
identical alignment requirements. That is, assuming that the required
cast is present.

Anyway, here is the chapter and verse:

7 A pointer to an object or incomplete type may be converted to
a pointer to a different object or incomplete type. If the
resulting pointer is not correctly aligned for the pointed-to
type, the behavior is undefined.

Doesn't quite match your statement, does it?

Dan

 

[James Hu]

[snip]

For one thing:

xref 4p2: If a "shall" or "shall not" requirement that appears
outside of a constraint is violated, the behavior is undefined.

And this sentence is repeated in the Appendix the summarizes
undefined behaviors. If a constraint violation implied undefined
behavior, I believe the standard would not have bothered to state
this exception.

Please engage your brain.

I have given you the benefit of the doubt. But even if I had not,
I would still give you the courtesy of keeping the sentiment to
myself.

Undefined behaviour as such does NOT require a diagnostic. Hence
the distinction: violating a shall inside a constraint requires a
diagnostic, violating a shall outside a constraint doesn't.

There is no need to make that distinction with the wording that I
quoted. 5.1.1.3 already makes it clear a constraint violation
requires a diagnostic, even in the cases it is explicitly stated
to cause undefined behavior. The quote:

xref 5.1.1.3p1: A conforming implementation shall produce at least
one diagnostic message ... 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.

So, if the sentence I cited in 4p2 just drops "that appears outside
of a constraint", a diagnostic would still be required for a constraint
violation. Instead, the standard clearly draws a line, as if to say
constraint violations do not necessarily imply undefined behavior.

The standard stil doesn't provide any clue about the behaviour of a
program violating a constraint, unless you can prove otherwise.

I have changed my mind. It is not unspecified behavior. My deduction
is now that the standard is realizing that a program with a constraint
violation may not exhibit any behavior whatsoever. Only if the
constraint violation also violates syntax or violates semantics does the
behavior of the program become undefined.

The example in 5.1.1.3 points to this:

xref 5.1.1.3p2: EXAMPLE An implementation shall issue a diagnostic
for the translation unit:

char i;
int i;

because in those cases where the wording in this International
Standard describes the behavior for a construct as being both
a constraint error and resulting in undefined behavior, the
constraint error shall be diagnosed.

The constraint error in this case is a violation of 6.7p3. But the
undefined behavior is the consequence of the defined semantics in
6.7.5p2.

That would be the case if the text said "because it allows the following".
As it is, the standard explains the semantics if the statement in question
were allowed by the language.

The standard explains why the statement is not actually allowed in
correct C programs. A compiler is not required to translate such code,
which wouldn't be the case if the code had valid semantics.

If the result of the constraint violation is undefined behavior, what
does it matter what the hypothetical semantics of it and following
statements would be? I don't think the standard would waste time
discussing hypothetical semantics, as such discussions should be
left in footnotes and rationales. The semantics are real, as if the
pointer conversion of the RHS was coerced via an implicit cast.

-- James