Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.lang.c
Subject: Re: *p++ = *p results?
Message-ID: <2412@utcsri.UUCP>
Date: Thu, 27-Mar-86 14:17:50 EST
Article-I.D.: utcsri.2412
Posted: Thu Mar 27 14:17:50 1986
Date-Received: Thu, 27-Mar-86 14:26:25 EST
References: <312@imagen.UUCP> <258@necis.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Distribution: net
Organization: CSRI, University of Toronto
Lines: 33
Summary: Some operators have a defined order of operation

In article <258@necis.UUCP> yde@necis.UUCP (David Elins ext. 220) writes:
>In article <312@imagen.UUCP> kevin@imagen.UUCP (Kevin L. Malloy) writes:
>>In the statement *p++ = *p; what will be the result? 

>My understanding, confirmed by lint, is that this is an ambiguous
>statement.  (lint said "warning: p evaluation order undefined")
>
...
>The real ambiguity is that C does not specify in which order the sides
>of an assignment operator (or any operator) get evaluated (c.f. K&R p. 49).
			       ^^^
The following operators have a defined order of execution:

a,b		first a, then b

a || b		eval a; if a==0 then b is evaluated

a && b		eval b; if a!=0 then b is evaluated

a ? b: c	eval a; if a!=0 then eval b else eval c.

This little point is very important, because much code depends on it.

This type of thing in particular is very common:

	if( p != NULL   &&   *p == What_I_am_looking_for )....

Evaluating *p will crash the program if p==NULL, but since the && operator
behaves the way it does, this will never happen.
-- 
"No eternal reward will forgive us now for wasting the dawn" -J. Morrison
----------------------------------------------------------------------
Greg Smith     University of Toronto       ..!decvax!utzoo!utcsri!greg