+++i

[Alex Fraser]

I think you mean constraint violation.

What is the distinction? Isn't what the standards term a constraint
violation just a type of semantic error?

Alex

 

[Keith Thompson]

What is the distinction? Isn't what the standards term a constraint
violation just a type of semantic error?

By some perfectly reasonable non-C-specific interpretations of the
phrase "semantic error", certainly. But many sections of the C
standard have 3 headers: "Syntax", "Constraints", and "Semantics".
"Syntax" describes the grammar of a construct, "Constraints" describes
certain mandatory restrictions that aren't expressible within the
grammar, and "Semantics" describes what it does. Violation of a
"Syntax" or "Constraints" rule requires a diagnostic; violation of
anything in the "Semantics" subsection invokes undefined behavior (or
is a failure of the implementation).

In the context of C, at least if you're trying to be precise, it's
probably good to limit the term "semantic error" to violations of
things listed under "Semantics", and refer to constraint violations
as, well, constraint violations.

 

[SM Ryan]

# > >I think you mean 'semantic error'.
# >
# > I think you mean constraint violation.
#
# What is the distinction? Isn't what the standards term a constraint
# violation just a type of semantic error?

Very few language definitions include formal context senstive syntax. Instead
the normal course is formal context free syntax, informal semantics, and
informal context sensitive syntax in between labelled variously as constraints
or semantics or static semantics.

There are readable context sensitive grammar schemes available.

 

[Dik T. Winter]

>
> Even when invoked as a C compiler?

Would it have been valid as a C++ construct? However, yes, invoked as
a C compiler. I never invoke it in another way. But whatever, look:

Sun.Ultra-4/apps/ksh: cat @@P.c
main()
{
int vthree = 0;
+vthree = 42;
return vthree;
}
Sun.Ultra-4/apps/ksh: gcc -ansi -pedantic -Wall @@P.c
@@P.c:2: warning: return-type defaults to `int'
Sun.Ultra-4/apps/ksh: gcc --version
2.95.2
Sun.Ultra-4/apps/ksh: a.out
Sun.Ultra-4/apps/ksh: echo $?
42
Sun.Ultra-4/apps/ksh:

 

[Dik T. Winter]

>
> With '+'. That is when one looks at the operators in the precedence
> "level" with the '++' and unary '+' it says precedence is left to rigth,

Not so. Moreover, the expression "x + + y" is handled as "x + (+ y)"
because of precedence. But parsing has really nothing to do with
precedence. The greedy algorithm is only textually greedy, that is,
it eats symbols while the resulting token makes sense.

> I would have thought, reading left to right and being greedy we'd get
>
> j = ++(+i);
>
> which is illegal.

That is right, but it has nothing to do with precedence.

 

[Dik T. Winter]

> (It's not an operator precedence thing; changing "+x = 42;" to "(+x) = 42;"
> makes no difference.)
>
> The same bug occurs in several other gcc releases. It was fixed
> some time between gcc 3.2 and 3.3.2.

What I remember from discussions quite some time ago, the unary + was
initially put into gcc by just ignoring it in almost all aspects. That
was the quickest way to put it in the compiler. But I think Chris Torek
knows more about it. A bit more experimenting leads me to believe that
gcc implemented it as a cast in some cases. Consider:
short vthree = 0;
+vthree = 42;
which elicits the error message:
ANSI C forbids use of cast expressions as lvalues

So it was only a partial implementation.

 

[Chris Torek]

What I remember from discussions quite some time ago, the unary + was
initially put into gcc by just ignoring it in almost all aspects. That
was the quickest way to put it in the compiler. But I think Chris Torek
knows more about it. ...

Not I; but it is not surprising that a quick-and-dirty implementation
just tosses it out along the way, in the easy cases. The old
Portable C Compiler used to have similar bugs: the front end stripped
out certain PCONV and/or SCONV nodes early on, so that things like
&(cast)var were sometimes accepted. (Worse, they were accepted if
and only if the type in the cast acted as a no-op when it came time
to generate code -- so when you moved code from a PDP-11 to a Vax,
it sometimes stopped compiling.)

A bit more experimenting leads me to believe that
gcc implemented it as a cast in some cases. Consider:
short vthree = 0;
+vthree = 42;
which elicits the error message:
ANSI C forbids use of cast expressions as lvalues

Which, interestingly, throws one back into the strange "implicit
and invisible cast" discussion. The invisible (and implicit?)
unary plus in "a = b" is also an implicit and invisible cast, except
when it is not.