Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!fluke!ssc-vax!uvicctr!sbanner1
From: sbanner1@uvicctr.UUCP (S. John Banner)
Newsgroups: comp.lang.c
Subject: A curriosity in the C compiler...
Message-ID: <530@uvicctr.UUCP>
Date: 25 Oct 88 22:00:28 GMT
Organization: University of Victoria, Victoria B.C. Canada
Lines: 67


   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