[comp.lang.c] A curriosity in the C compiler...

sbanner1@uvicctr.UUCP (S. John Banner) (10/26/88)

   I have recently had some fun installing tn3270 on a Sun4, and I
found something which I think looks like a bug, but I wantted to
show a few other people and see what they thing first.  The short
program below demonstrates the problem, it does the same thing on
both the Sun4, and our Sun 3/280.

----Start of program...

#include <stdio.h>
#include <varargs.h>

/*
	This is a quick test of the C compiler, for implied bracketing...
This will determine if the expression "a = b == c" is parsed
as "(a = b) == c" (which is correct), or as "a = (b == c)" (which
is not).
*/

main(argc, argv)
int argc;
char *argv[];
{
int
	a,b,c;

	test("one", "two", "three", (char *)NULL);
}


test(va_alist)
va_dcl
{
va_list
	RealArgs;
int
	Cnt;
char
	*Args[5];

va_start(RealArgs);
for (Cnt=0;Args[Cnt]=va_arg(RealArgs, char *)!=(char *)NULL; Cnt++)
	printf("%s %d\n", Args[Cnt], Cnt);
va_end(RealArgs);
}

-----End of program...

The offending like is the for loop inside the procedure.  What I get
is a segmentation fault (on the printf), and when you look at the
values in Args[0], it is equal to "1".  To make it work correctly
you need only put parenthesis arround the assignment to Args[Cnt],
(or now that I look at it, probably arround the "call" to va_arg),
but it strikes me that this really should not be required.  Comment?

		Thanks,

		     sjb.


                      S. John Banner

...!uw-beaver!uvicctr!sol!sbanner1
...!ubc-vision!uvicctr!sol!sbanner1
ccsjb@uvvm.bitnet  (Please avoid this address if possible)
sbanner1%sol.uvic.cdn@ubc.csnet
sbanner1@sol.uvic.ca

ok@quintus.uucp (Richard A. O'Keefe) (10/28/88)

In article <530@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes:
>	This is a quick test of the C compiler, for implied bracketing...
>This will determine if the expression "a = b == c" is parsed
>as "(a = b) == c" (which is correct), or as "a = (b == c)" (which is not).

Surely there is some mistake here: == binds more tightly than = does.
You wouldn't expect "a = b + c" to be parsed as "(a=b) + c" would you?
The bracketing "a = (b == c)" is correct according to an old ANSI draft
I checked, and according to cparen [never leave for work without it].

The Sequent C compiler complained about an illegal pointer/integer
combinition in line 23 (counting the first #include as line 1) which
is the for(..) loop.

maart@cs.vu.nl (Maarten Litmaath) (10/28/88)

In article <530@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes:
\/*
\	This is a quick test of the C compiler, for implied bracketing...
\This will determine if the expression "a = b == c" is parsed
\as "(a = b) == c" (which is correct), or as "a = (b == c)" (which
\is not).
\*/

The `=' operator has lower priority than `==', so the SECOND parsing is
correct. I thought this was VERY basic C knowledge...
(In case you find the precedence strange: think of `a' as a boolean in which
is stored if `b' and `c' are equal or not.)
-- 
George Bush:                          |Maarten Litmaath @ VU Amsterdam:
             Capt. Slip of the Tongue |maart@cs.vu.nl, mcvax!botter!maart

henry@utzoo.uucp (Henry Spencer) (10/29/88)

In article <530@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes:
>This will determine if the expression "a = b == c" is parsed
>as "(a = b) == c" (which is correct), or as "a = (b == c)" (which
>is not).

Wrong.  It's the other way round.
-- 
The dream *IS* alive...         |    Henry Spencer at U of Toronto Zoology
but not at NASA.                |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

ark@alice.UUCP (Andrew Koenig) (10/29/88)

In article <530@uvicctr.UUCP>, sbanner1@uvicctr.UUCP (S. John Banner) writes:
 
> /*
> 	This is a quick test of the C compiler, for implied bracketing...
> This will determine if the expression "a = b == c" is parsed
> as "(a = b) == c" (which is correct), or as "a = (b == c)" (which
> is not).
> */

The expression

	a = b == c

is correctly parsed as

	a = (b == c)

despite the comment above to the contrary.
-- 
				--Andrew Koenig
				  ark@europa.att.com

billd@celerity.UUCP (Bill Davidson) (10/29/88)

In article <530@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes:
>	This is a quick test of the C compiler, for implied bracketing...
>This will determine if the expression "a = b == c" is parsed
>as "(a = b) == c" (which is correct), or as "a = (b == c)" (which is not).

ACK!  Please refer to page 49 of K&R or any other C book which has a
precedence table.  "a = b == c" must be parsed as "a = (b == c)" by
laws of precedence which have been in C for a very long time.

A C programmer who does not know his precedence laws by heart had better
use a lot of parentheses or he can expect a LOT of problems.

	--Bill Davidson

These are my own opinions and FPS doesn't even know about them.
	....!ucsd!celerity!billd

al710@unh.UUCP (Anthony Lapadula) (10/31/88)

In article <181@celerity.UUCP>, billd@celerity.UUCP (Bill Davidson) writes:
> In article <530@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes:
> >	This is a quick test of the C compiler, for implied bracketing...
> >This will determine if the expression "a = b == c" is parsed
> >as "(a = b) == c" (which is correct), or as "a = (b == c)" (which is not).
> 
> ACK!  Please refer to page 49 of K&R or any other C book which has a
> precedence table.  "a = b == c" must be parsed as "a = (b == c)" by
> laws of precedence which have been in C for a very long time.
> 
> A C programmer who does not know his precedence laws by heart had better
> use a lot of parentheses or he can expect a LOT of problems.
>
> 	--Bill Davidson

Maybe it's just me (and it probably is), but isn't
      a = (b == c)
a whole lot clearer than
      a = b == c
?  (And where the heck should that question mark go, anyway?)

It seems that the first version clearly points out that 'a' is being
used as a boolean, where the second one is more of an exercise left
for the reader.

Just trying to stir up another one of those "= looks too much like ==
to me" arguments....

/*
**      What, you wanted something funny?
**             --- Anthony Lapadula (...!unh!al710)
*/

crossgl@ingr.UUCP (Gordon Cross) (11/01/88)

In article <530@uvicctr.UUCP>, sbanner1@uvicctr.UUCP (S. John Banner) writes:
> 
> /*
> 	This is a quick test of the C compiler, for implied bracketing...
> This will determine if the expression "a = b == c" is parsed
> as "(a = b) == c" (which is correct), or as "a = (b == c)" (which
> is not).
> */

The correct treatment of the expression a = b == c is a = (b == c) and NOT
(a = b) == c!!  Check your info on operator precedence.  I believe that you
will discover that == has higher precedence than =.


Gordon Cross
Intergraph Corp.  Huntsville, AL