Xref: utzoo comp.arch:8370 comp.lang.c:16433
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!cfisun!lakart!dg
From: dg@lakart.UUCP (David Goodenough)
Newsgroups: comp.arch,comp.lang.c
Subject: Re: Fun C typos (was *p++ = *q++)
Message-ID: <436@lakart.UUCP>
Date: 21 Feb 89 15:26:25 GMT
References: <EJP.89Feb16173101@faron.icd.abnet.COM>
Distribution: usa
Organization: Lakart Corporation, Newton, MA
Lines: 40

From article <EJP.89Feb16173101@faron.icd.abnet.COM>, by ejp@faron.icd.abnet.COM (Ed Prochak):
> In article <15908@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>   This is not the proper group for this, but I have to say *something*.
>>   That is not how for loops work in C, and the true-value of any comparison
>>   operator in *any* correct C compiler is 1 (not -1, not 17, not 42, 1).
>>   The latter in particular in a common misconception, probably left over
>>   from FORTRAN (and BASIC) systems that used -1 as .TRUE..
> Chris,
> 	He said nothing about the value that resulted from the comparison.
> He said, "TRUE is not 0". and that is correct. Kernighan and Ritchie state
> exactly that, on page 38 to be specific. A TRUE value in C does not have to
> be 1 (one) for it to be a "correct C compiler". In C
> 	FALSE	=	0
> 	TRUE	=	NOT FALSE

There are two things being dealt with here:

	if (1) .......

	if (2) ........

	if (3) .........

All the above if() will execute the "true" code, because 1, 2, 3, any non-zero
value is true.

	 a = (1 == 1);

	 b = (2 == 2);

	 c = (3 == 3);

will assign 1 into a, b, c; not -1, 42, 377, or anything else, but 1.

_THIS_ is what Chris was saying, and is distinct from the above if () widgetry.
-- 
	dg@lakart.UUCP - David Goodenough		+---+
						IHS	| +-+-+
	....... !harvard!xait!lakart!dg			+-+-+ |
AKA:	dg%lakart.uucp@xait.xerox.com		  	  +---+