Constraint violation - when?

[Pietro Cerutti]

Dear all,

I would like to open another topic to try to clarify a doubt raised on
my previous post today with the subject 'printf("%d%d%d ")'.

Reading through the standard, I cannot find a clear definition of what
is a constraint violation.

Repeating the citation:
3.8
1 constraint
restriction, either syntactic or semantic, by which the exposition
of language elements is to be interpreted

As I understand it, a constraint is any explicit syntax or semantic rule.

Still, i = i++; is not a constraint violation.

Why? The standard clearly says that a variable cannot be modified more
than once within a single sequence point. The aforementioned code
modifies i twice. Isn't it a semantical rule being violated?

P.S. It's incredible how many things I get wrong reading the standard....

--
Pietro Cerutti

[santosh]

Re: Constraint violation - when?

Pietro Cerutti <gahr_SPAM_gahr _ME_chwrote:

Dear all,
>
I would like to open another topic to try to clarify a doubt raised on
my previous post today with the subject 'printf("%d%d%d ")'.
>
Reading through the standard, I cannot find a clear definition of what
is a constraint violation.
>
Repeating the citation:
3.8
1 constraint
restriction, either syntactic or semantic, by which the
exposition of language elements is to be interpreted
>
As I understand it, a constraint is any explicit syntax or semantic
rule.
>
Still, i = i++; is not a constraint violation.
>
Why? The standard clearly says that a variable cannot be modified more
than once within a single sequence point. The aforementioned code
modifies i twice. Isn't it a semantical rule being violated?
>
P.S. It's incredible how many things I get wrong reading the
standard....

From n1256.pdf

4. Conformance

1 In this International Standard, ??shall?? is to be interpreted as a
requirement on an implementation or on a program; conversely, ??shall
not?? is to be interpreted as a prohibition.
2 If a ??shall?? or ??shall not?? requirement that appears outside of a
constraint is violated, the behavior is undefined. Undefined behavior
is otherwise indicated in this International Standard by the
words ??undefined behavior?? or by the omission of any explicit
definition of behavior. There is no difference in emphasis among these
three; they all describe ??behavior that is undefined??.

[Pietro Cerutti]

Re: Constraint violation - when?

santosh wrote:

Pietro Cerutti <gahr_SPAM_gahr _ME_chwrote:
>

>Dear all,
>>
>I would like to open another topic to try to clarify a doubt raised on
>my previous post today with the subject 'printf("%d%d%d ")'.
>>
>Reading through the standard, I cannot find a clear definition of what
>is a constraint violation.
>>
>Repeating the citation:
>3.8
>1 constraint
> restriction, either syntactic or semantic, by which the
> exposition of language elements is to be interpreted
>>
>As I understand it, a constraint is any explicit syntax or semantic
>rule.
>>
>Still, i = i++; is not a constraint violation.
>>
>Why? The standard clearly says that a variable cannot be modified more
>than once within a single sequence point. The aforementioned code
>modifies i twice. Isn't it a semantical rule being violated?
>>
>P.S. It's incredible how many things I get wrong reading the
>standard....

>
From n1256.pdf
>
4. Conformance
>
1 In this International Standard, ??shall?? is to be interpreted as a
requirement on an implementation or on a program; conversely, ??shall
not?? is to be interpreted as a prohibition.
2 If a ??shall?? or ??shall not?? requirement that appears outside of a
constraint is violated, the behavior is undefined. Undefined behavior
is otherwise indicated in this International Standard by the
words ??undefined behavior?? or by the omission of any explicit
definition of behavior. There is no difference in emphasis among these
three; they all describe ??behavior that is undefined??.
>

Great, thanks. I think I've got it now...

--
Pietro Cerutti

[James Kuyper]

Re: Constraint violation - when?

Pietro Cerutti wrote:

Dear all,
>
I would like to open another topic to try to clarify a doubt raised on
my previous post today with the subject 'printf("%d%d%d ")'.
>
Reading through the standard, I cannot find a clear definition of what
is a constraint violation.
>
Repeating the citation:
3.8
1 constraint
restriction, either syntactic or semantic, by which the exposition
of language elements is to be interpreted

I agree that this description is quite elliptic; I've never been able to
attach any clear meaning to the part after the second comma. However,
all is not lost --

As I understand it, a constraint is any explicit syntax or semantic rule.

Whatever it is that they meant to say in the definition above, it
appears, from the way the standard uses the term, that syntax rules are
distinct from syntactic constraints, and that semantic rules are
distinct from semantic constraints.

All you have to do to identify a constraint is to look at the title of
the section where you found it. If that title is "constraint s", then
it's a constraint; otherwise it's something else. Exception:
5.1.2.2.1p2, 6.10p2.

Lawrence Jones: wouldn't it be more consistent if 5.1.2.2.1p2 and 6.10p2
were not exceptions to this pattern?

[Ben Bacarisse]

Re: Constraint violation - when?

Pietro Cerutti <gahr_SPAM_gahr _ME_chwrites:

<snip>

Still, i = i++; is not a constraint violation.
>
Why?

To add a little more... It is not a constraint violation because
constraints must be checked by the implementation and violations of
this rule (no multiple updates between sequence points) are hard to
diagnose in general (in fact it is not possible to detect this in
every case).

--
Ben.

[Pietro Cerutti]

Re: Constraint violation - when?

Ben Bacarisse wrote:

Pietro Cerutti <gahr_SPAM_gahr _ME_chwrites:
>
<snip>

>Still, i = i++; is not a constraint violation.
>>
>Why?

>
To add a little more... It is not a constraint violation because
constraints must be checked by the implementation and violations of
this rule (no multiple updates between sequence points) are hard to
diagnose in general (in fact it is not possible to detect this in
every case).
>

Thanks for this point Ben. Then it's more about commodity to check than
about exact rules of the language.

--
Pietro Cerutti

[Pietro Cerutti]

Re: Constraint violation - when?

James Kuyper wrote:

Pietro Cerutti wrote:

>Dear all,
>>
>I would like to open another topic to try to clarify a doubt raised on
>my previous post today with the subject 'printf("%d%d%d ")'.
>>
>Reading through the standard, I cannot find a clear definition of what
>is a constraint violation.

[snip]

All you have to do to identify a constraint is to look at the title of
the section where you found it. If that title is "constraint s", then
it's a constraint; otherwise it's something else. Exception:
5.1.2.2.1p2, 6.10p2.

This is a very good and practical hint! Thanks!


--
Pietro Cerutti

[Keith Thompson]

Re: Constraint violation - when?

Pietro Cerutti <gahr_SPAM_gahr _ME_chwrites:

Ben Bacarisse wrote:

>Pietro Cerutti <gahr_SPAM_gahr _ME_chwrites:
><snip>

>>Still, i = i++; is not a constraint violation.
>>>
>>Why?

>To add a little more... It is not a constraint violation because
>constraints must be checked by the implementation and violations of
>this rule (no multiple updates between sequence points) are hard to
>diagnose in general (in fact it is not possible to detect this in
>every case).

>
Thanks for this point Ben. Then it's more about commodity to check
than about exact rules of the language.

It's more about the fact that the standard's definition of
"constraint " in C99 3.8 is too vague.

If you think of a "constraint " as "any requirement that's in a section
marked 'Constraints'", there's little or no ambiguity.

And yes, the set of requirements that are "constraint s" was carefully
chosen to allow them to be reliable checked by the compiler. If it
were practical to diagnose "i = i++;" at compile time, it probably
would have been made a constraint.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: Constraint violation - when?

James Kuyper <jameskuyper@ve rizon.netwrites :
[...]

All you have to do to identify a constraint is to look at the title of
the section where you found it. If that title is "constraint s", then
it's a constraint; otherwise it's something else. Exception:
5.1.2.2.1p2, 6.10p2.
>
Lawrence Jones: wouldn't it be more consistent if 5.1.2.2.1p2 and
6.10p2 were not exceptions to this pattern?

In 5.1.2.2.1p2:

If they are declared, the parameters to the main function shall
obey the following constraints:
...

the word "constraint s" is being used in a manner that's consistent
with the vague definition in 3.8, but not with the general usage of
the term "constraint " as a requirement whose violation can be
diagnosed at compile time.

The use of term "constraint s" in 6.10p2 is also rather odd. Something
that violates the listed "constraint s" isn't necessarily a diagnosable
error; it's just not a preprocessing directive.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jameskuyper@verizon.net]

Re: Constraint violation - when?

Keith Thompson wrote:

James Kuyper <jameskuyper@ve rizon.netwrites :
[...]

All you have to do to identify a constraint is to look at the title of
the section where you found it. If that title is "constraint s", then
it's a constraint; otherwise it's something else. Exception:
5.1.2.2.1p2, 6.10p2.

Lawrence Jones: wouldn't it be more consistent if 5.1.2.2.1p2 and
6.10p2 were not exceptions to this pattern?

Note: I got an autormated reply that he's on vacation until 8/11

>
In 5.1.2.2.1p2:
>
If they are declared, the parameters to the main function shall
obey the following constraints:
...
>
the word "constraint s" is being used in a manner that's consistent
with the vague definition in 3.8, but not with the general usage of
the term "constraint " as a requirement whose violation can be
diagnosed at compile time.

Yes, those are run-time constraints on the implementation, rather than
compile-time constraints on the program.

The use of term "constraint s" in 6.10p2 is also rather odd. Something
that violates the listed "constraint s" isn't necessarily a diagnosable
error; it's just not a preprocessing directive.

You're right: I just did a quick search for "constraint ". I thought
those were just a couple of inconsistencies that slipped past the
editor. If I'd thought about it a little longer, I'd have realize why
these two were handled differently than the other "contraint"
sections.

[Pietro Cerutti]

Re: Constraint violation - when?

Keith Thompson wrote:

Pietro Cerutti <gahr_SPAM_gahr _ME_chwrites:

>Ben Bacarisse wrote:

>>Pietro Cerutti <gahr_SPAM_gahr _ME_chwrites:
>><snip>
>>>Still, i = i++; is not a constraint violation.
>>>>
>>>Why?
>>To add a little more... It is not a constraint violation because
>>constraints must be checked by the implementation and violations of
>>this rule (no multiple updates between sequence points) are hard to
>>diagnose in general (in fact it is not possible to detect this in
>>every case).

>Thanks for this point Ben. Then it's more about commodity to check
>than about exact rules of the language.

>
It's more about the fact that the standard's definition of
"constraint " in C99 3.8 is too vague.
>
If you think of a "constraint " as "any requirement that's in a section
marked 'Constraints'", there's little or no ambiguity.
>
And yes, the set of requirements that are "constraint s" was carefully
chosen to allow them to be reliable checked by the compiler. If it
were practical to diagnose "i = i++;" at compile time, it probably
would have been made a constraint.
>

Thanks!

--
Pietro Cerutti

[lawrence.jones@siemens.com]

Re: Constraint violation - when?

James Kuyper <jameskuyper@ve rizon.netwrote:

Pietro Cerutti wrote:

Repeating the citation:
3.8
1 constraint
restriction, either syntactic or semantic, by which the exposition
of language elements is to be interpreted

>
I agree that this description is quite elliptic; I've never been able to
attach any clear meaning to the part after the second comma.

Originally (way back when that definition was written), the philosophy
was that constraints were what told you whether a string of characters
was actually a C translation unit or just a string of characters. The
primary thing that does that is the syntax grammar rules, but there are
some rules that are difficult (if not impossible) to represent in the
syntax, so they are stated in plain text in specially labeled sections
instead. For example, the grammar is ambiguous as to whether the
characters ``<foo>'' should be interpreted as a header name or as a
less-than operator, an identifier, and a greater-than operator; that was
disambiguated by a constraint that said that header names are only
recognized in #include directives. So the constraints were viewed as an
adjuct to the grammar, which tells you how to interpret (parse) the
language elements.

The grammar has since been revised and that constraint revised and moved
to semantics (and that's the only example I can think of where a
constraint actually affected the grammar), and the grammar rules are no
longer viewed as contraints but as something separate, so the definition
now leaves something to be desired, but not enough that anyone (on the
committee) has felt a burning need to change it.
--
Larry Jones

You should see me when I lose in real life! -- Calvin

[jameskuyper@verizon.net]

Re: Constraint violation - when?

lawrence.jo...@ siemens.com wrote:

James Kuyper <jameskuyper@ve rizon.netwrote:

Pietro Cerutti wrote:

>
Repeating the citation:
3.8
1 constraint
restriction, either syntactic or semantic, by which the exposition
of language elements is to be interpreted

I agree that this description is quite elliptic; I've never been able to
attach any clear meaning to the part after the second comma.

>
Originally (way back when that definition was written), the philosophy
was that constraints were what told you whether a string of characters
was actually a C translation unit or just a string of characters.

I find that explanation much clearer than the standard's wording,
though it would probably need to be a little more formal before it
could be adopted as a replacement for the current definition. If it
were adopted, it would also provide an authoritative basis for
answering the overly-debated question: "Can a program containing
feature X still be considered a C program?".