Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!hpda!fortune!olson
From: olson@fortune.UUCP
Newsgroups: net.lang.c
Subject: Re: & operator - (nf)
Message-ID: <2006@fortune.UUCP>
Date: Thu, 15-Dec-83 19:04:44 EST
Article-I.D.: fortune.2006
Posted: Thu Dec 15 19:04:44 1983
Date-Received: Mon, 19-Dec-83 00:09:24 EST
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 25

#R:iwu1a:-16200:fortune:16200014:000:943
fortune!olson    Dec 15 12:19:00 1983

(This was in reply to Paul Fox (eagle!hou5h!pgf), who sent me mail)

I agree with the part about in being incremented after used. What I
disagree_d_ with was the idea that &(*in++) is the same as &*in++.

Page 186 of K+R says (2nd para.) that the type and VALUE of a
parenthesized expression is identical to the unadorned expression.  In
this case the expression evaluates to the original CHARACTER pointed to
by in.

The more research and thought I give to this, the more I suspect that
my original position was wrong; the KEY POINT being the last sentence
of the above paragraph.  This is yet another case of not pondering the
question long enough before replying.

As a matter of interest, the compilers on my 4.1bsd vax, and on my
Fortune 32:16 both assign 'out' the UNincremented value of 'in',
indicating that those compiler writers agree with your interpretation.

	Dave Olson, Fortune Systems
	{ihnp4,harpo,ucbvax!amd70}!fortune!olson