[comp.lang.c] Compiler Error?

greim@sbsvax.UUCP (Michael Greim) (02/15/89)

This is about pre-ANSI C.

Consider the following program:

------ cut -------------------
# include <stdio.h>

main ()
{
	int i, j, k;
	i = 5;
	j = 0;
	k = 0;
	if (i == 5)
		(j = 2) ? k = 3 : 4;
	printf ("j = %d, k = %d\n", j, k);
}
------- cut -----------------

On 43BSD, SunOS 3.4, ULTRIX 2.0 this compiles with no error.

According to the C books I could get my hands on,
"?:" has higher precedence than the assignment operators, like
"=" for instance. (In X3J11 too)

Thus the compiler should find an error in the statement, something
like "misplaced assignment".

SIEMENS SINIX v2.1 finds an error.

Is it really a compiler error? In all the major compilers?
And nobody has noticed it yet? :-)
Is it a typical pcc error?
How does GNU perform?
What about the ANSI compilers?

	-mg

PS.: I found such a statement in GNU grep, when I was porting it to SINIX.
-- 
email : greim@sbsvax.informatik.uni-saarland.dbp.de
  (some mailers might not like this. Then use greim@sbsvax.uucp)
  or  : ...!uunet!unido!sbsvax!greim
# include <disclaimers/std.h>

jas@ernie.Berkeley.EDU (Jim Shankland) (02/16/89)

In article <683@sbsvax.UUCP> greim@sbsvax.UUCP (Michael Greim) writes:
>This is about pre-ANSI C.
>
> [Is the following legal C?]
>		(j = 2) ? k = 3 : 4;

I.e., is the assignment statement between the ? and the : legal, given
that = has lower precedence than ?:.

This issue comes up periodically.  The answer is unclear.  K & R
doesn't rightly say whether this is legal, though people have made
casuistic arguments on both sides.  I *will* note that it's
unambiguous and easily parsable, so perhaps there's no reason to
disallow it.  No doubt the pANS has resolved this one way or the other.
Meanwhile, I claim:  if you're writing a compiler, allow it; if you're
writing code, don't use it.

Jim Shankland
jas@ernie.berkeley.edu

"I've been walking in a river all my life, and now my feet are wet"

gjoost@westc.UUCP (Gertjan van Oosten) (02/16/89)

In article <683@sbsvax.UUCP> greim@sbsvax.UUCP (Michael Greim) writes:
>Consider the following program:
...
>		(j = 2) ? k = 3 : 4;
...
>On 43BSD, SunOS 3.4, ULTRIX 2.0 this compiles with no error.
>
>According to the C books I could get my hands on,
>"?:" has higher precedence than the assignment operators, like
>"=" for instance. (In X3J11 too)

Your quote from the C-books is right, but you should read it more
carefully:
	"?:" has higher precedence than assignment.
	  ^
	  +--- spot the colon there!

So this means, that an expression like:
	a = b ? c : d
is parsed as:
	a = (b ? (c) : d)
"?:" is a ternary operator, with operands b, c and d (assuming that
b and d don't contain unparenthesised expressions containing lower
precedence operators).

>Thus the compiler should find an error in the statement, something
>like "misplaced assignment".

No, it shouldn't.

>SIEMENS SINIX v2.1 finds an error.

Siemens SINIX v2.1 is an error. :-)

               Yours sincerely,

			   G. J. van Oosten.

"Peace on earth and mercy mild, Mother Brown has lost her child.
 Just another forgotten son....."
	Marillion, "Forgotten Sons"

mike@thor.stolaf.edu (Mike Haertel) (02/17/89)

In article <683@sbsvax.UUCP> greim@sbsvax.UUCP (Michael Greim) writes:
>Consider the following program:
...
>		(j = 2) ? k = 3 : 4;
...
>According to the C books I could get my hands on,
>"?:" has higher precedence than the assignment operators, like
>"=" for instance. (In X3J11 too)
>
>Thus the compiler should find an error in the statement, something
>like "misplaced assignment".

No.  That this works is not an error.  Precedence rules are used
to resolve ambiguity about which of two neighboring operators
an expression belongs to.  In this case, the assignment statement
is in the middle of an operator, so to speak, so there is no
ambiguity.

>PS.: I found such a statement in GNU grep, when I was porting it to SINIX.

Don't send a bug report about GNU grep because I won't change it just for
the benefit of some brain damaged compiler without a proper parser.

	Mike Haertel