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