Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!ucsfcgl!cgl.ucsf.edu!kneller
From: kneller@cgl.ucsf.edu (Don Kneller)
Newsgroups: comp.sys.ibm.pc
Subject: Re: TC2.0 bugfree ?
Message-ID: <11323@cgl.ucsf.EDU>
Date: 20 Jan 89 19:01:30 GMT
References: <3785@druwy.ATT.COM>
Sender: daemon@cgl.ucsf.edu
Reply-To: kneller@socrates.ucsf.edu.UUCP (Don Kneller)
Organization: UCSF Computer Graphics Lab
Lines: 35

In article <3785@druwy.ATT.COM> rhm@druwy.UUCP (MasseyR) writes:
>No bugs in TC2.0 ?
>
>sub( cp )
>unsigned char 	*cp;
>{
>	int 	i;
>
>	i = (*cp++ << 8) + *cp++;
>}
>
>[ ASM code removed which shows cp is not incremented between references
>  but instead after both references - dgk ]

This is perfectly valid behavior.  Not exactly DWIM, but certainly not
disallowed.  In essence, foo++ in an expression means to use the value
of foo and, sometime before proceeding to the next line, increment the
value of foo.  We all know what you mean to say in the above expression,
but you don't have complete control over the order of evaluation!  That
is, you have no control over which of (*cp++ << 8) or *cp++ is first
to be evaluated.  The compiler makers are free to do whatever they please.

The take-home lesson (as such) is for C programmers to never depend on
the order of evaluation in expressions where the operators have equal
precedence.  Currently C has no way of forcing the order.  Only a few
operators can force explicit order (e.g. || && ,).

- don

P.S.  I recently fell for (getchar() << 8) + getchar().
-----
	Don Kneller
UUCP:		...ucbvax!ucsfcgl!kneller
INTERNET:	kneller@cgl.ucsf.edu
BITNET:		kneller@ucsfcgl.BITNET