Richard Damon <Richard@Damon-Family.org> writes:
> On 1/3/22 3:03 PM, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [ is a constraint violation always undefined behavior? ]
>>
>>> [...] one possible interpretation of the phrase "a restriction
>>> ... by which the exposition of language elements is to be
>>> interpreted" could be that if the constraint is violated, there
>>> is no meaningful interpretation. Or to put it another way,
>>> that the semantic description applies only if all constraints
>>> are satisfied.
>>>
>>> I've searched for the word "constraint" in the C89 and C99
>>> Rationale documents. They were not helpful.
>>>
>>> I am admittedly trying to read into the standard what I think
>>> it *should* say. A rule that constraint violations cause
>>> undefined behavior would, if nothing else, make the standard a
>>> bit simpler.
>> Note that constraint violations are not undefined behavior in a
>> strict literal reading of the definition. Undefined behavior
>> means there are no restrictions as to what an implemenation may
>> do, but constraint violations require the implementation to
>> issue at least one diagnostic, which is not the same as "no
>> restrictions".
>
> Although, after issuing that one diagnostic, if the implementation
> continues and generates an output program, and that program is run,
> then its behavior is explicitly defined to be undefined behavior.

Explicitly? Where does the standard say that.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On Monday, January 3, 2022 at 3:56:22 PM UTC-5, Tim Rentsch wrote:
> Keith Thompson <Keith.S.T...@gmail.com> writes:
>
> > James Kuyper <james...@alumni.caltech.edu> writes:
....
> >> The standard says nothing to that effect. The only meaningful
> >> thing it says is that a diagnostic is required (5.1.1.3p1). I do
> >> not consider the standard's definition of "constraint" to be
> >> meaningful: "restriction, either syntactic or semantic, by which
> >> the exposition of language elements is to be interpreted" (3.8).
....
> > The standard's definition of "constraint" is uncomfortably vague
> > -- but that doesn't mean I'm comfortable ignoring it.
> >
> > Given the definition of a "constraint" as a "restriction, either
> > syntactic or semantic, by which the exposition of language
> > elements is to be interpreted", it seems to me to be at least
> > plausible that when a constraint is violated, the "exposition of
> > language elements" cannot be interpreted.
....
> > I'm not saying that this is the only way to interpret that wording.
> > It's vague enough to permit a number of reasonable readings. [...]
>
> So you're saying that the meaning of the definition of constraint
> is to some extent subjective, ie, reader dependent?

As I said above, it seems to me to be so poorly worded that it's not
clear to me that it has any meaning, much less one that is subjective.
Since other people disagree with me on that point, there would
appear to be some subjectivity at play in that judgment, but after
reading their arguments, I remain at a loss as to how they can
interpret that phrase as being meaningful.

On 1/3/22 4:45 PM, Richard Damon wrote:
> On 1/3/22 3:03 PM, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [ is a constraint violation always undefined behavior? ]
>>
>>> [...] one possible interpretation of the phrase "a restriction
>>> ... by which the exposition of language elements is to be
>>> interpreted" could be that if the constraint is violated, there
>>> is no meaningful interpretation. Or to put it another way,
>>> that the semantic description applies only if all constraints
>>> are satisfied.
>>>
>>> I've searched for the word "constraint" in the C89 and C99
>>> Rationale documents. They were not helpful.
>>>
>>> I am admittedly trying to read into the standard what I think
>>> it *should* say. A rule that constraint violations cause
>>> undefined behavior would, if nothing else, make the standard a
>>> bit simpler.
>>
>> Note that constraint violations are not undefined behavior in a
>> strict literal reading of the definition. Undefined behavior
>> means there are no restrictions as to what an implemenation may
>> do, but constraint violations require the implementation to
>> issue at least one diagnostic, which is not the same as "no
>> restrictions".
>
> Although, after issuing that one diagnostic, if the implementation
> continues and generates an output program, and that program is run, then
> its behavior is explicitly defined to be undefined behavior.

Where? The standard specifies that there are only two explicit ways
whereby undefined behaviro is indicated: a "shall" or "shall not" that
appears outside of a constraint or runtime-constraint, or the use of the
words "undefined behavior". In which clause to is there a relevant use
of "shall", "shall not" or "undefined behavior"?

There's one implicit method, and that's "by the omission of any explicit
definition of behavior", but I've argued that there is an explicit
definition of the behavior that applies in this case. In the absence of
a general statement that "a constraint shall be satisfied" or "a
constraint shall not be violated" or "violation of a constraint has
undefined behavior", or some other corresponding wording that qualifies
as explicitly making the behavior undefined, the existence of that
explicit definition of behavior is not erased by the constraint violation.
If a constraint violation does not render an explicit definition of the
behavior inapplicable, the only consequences of that violation are a
mandatory diagnostic and permission to reject the program. Should an
implementation choose not to reject the program, and should the
resulting executable be run, the behavior of that program is still
constrained by all of the requirements of the standard.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On Monday, January 3, 2022 at 3:56:22 PM UTC-5, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.T...@gmail.com> writes:
>>
>>> James Kuyper <james...@alumni.caltech.edu> writes:
>
> ...
>
>>>> The standard says nothing to that effect. The only meaningful
>>>> thing it says is that a diagnostic is required (5.1.1.3p1). I do
>>>> not consider the standard's definition of "constraint" to be
>>>> meaningful: "restriction, either syntactic or semantic, by which
>>>> the exposition of language elements is to be interpreted" (3.8).
>
> ...
>
>>> The standard's definition of "constraint" is uncomfortably vague
>>> -- but that doesn't mean I'm comfortable ignoring it.
>>>
>>> Given the definition of a "constraint" as a "restriction, either
>>> syntactic or semantic, by which the exposition of language
>>> elements is to be interpreted", it seems to me to be at least
>>> plausible that when a constraint is violated, the "exposition of
>>> language elements" cannot be interpreted.
>
> ...
>
>>> I'm not saying that this is the only way to interpret that wording.
>>> It's vague enough to permit a number of reasonable readings. [...]
>>
>> So you're saying that the meaning of the definition of constraint
>> is to some extent subjective, ie, reader dependent?
>
> As I said above, it seems to me to be so poorly worded that it's not
> clear to me that it has any meaning, much less one that is subjective.
> Since other people disagree with me on that point, there would
> appear to be some subjectivity at play in that judgment, but after
> reading their arguments, I remain at a loss as to how they can
> interpret that phrase as being meaningful.

So is what you're saying that whether the meaning is subjective is
itself a subjective question?

Richard Damon <Richard@Damon-Family.org> writes:

> On 1/3/22 3:03 PM, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [ is a constraint violation always undefined behavior? ]
>>
>>> [...] one possible interpretation of the phrase "a restriction
>>> ... by which the exposition of language elements is to be
>>> interpreted" could be that if the constraint is violated, there
>>> is no meaningful interpretation. Or to put it another way,
>>> that the semantic description applies only if all constraints
>>> are satisfied.
>>>
>>> I've searched for the word "constraint" in the C89 and C99
>>> Rationale documents. They were not helpful.
>>>
>>> I am admittedly trying to read into the standard what I think
>>> it *should* say. A rule that constraint violations cause
>>> undefined behavior would, if nothing else, make the standard a
>>> bit simpler.
>>
>> Note that constraint violations are not undefined behavior in a
>> strict literal reading of the definition. Undefined behavior
>> means there are no restrictions as to what an implemenation may
>> do, but constraint violations require the implementation to
>> issue at least one diagnostic, which is not the same as "no
>> restrictions".
>
> Although, after issuing that one diagnostic, if the implementation
> continues and generates an output program, and that program is run,
> then its behavior is explicitly defined to be undefined behavior.

I don't think so. It may be the case that the C standard is
meant to imply that a constraint violation will necessarily
also result in undefined behavior, but AFAICT there is no
explicit statement to that effect.