Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!rochester!cornell!batcomputer!braner
From: braner@batcomputer.UUCP
Newsgroups: comp.lang.c
Subject: Re: incrementing after a cast
Message-ID: <1777@batcomputer.tn.cornell.edu>
Date: Wed, 10-Dec-86 00:04:47 EST
Article-I.D.: batcompu.1777
Posted: Wed Dec 10 00:04:47 1986
Date-Received: Sun, 14-Dec-86 02:00:21 EST
References: <349@apple.UUCP> <7376@utzoo.UUCP> <1746@batcomputer.tn.cornell.edu> <264@bobkat.UUCP>
Reply-To: braner@batcomputer.UUCP (braner)
Organization: Theory Center, Cornell University, Ithaca NY
Lines: 23
Keywords: cast, increment, postincrement

[]

I tried to be brief and got dumped on...

When I suggested a standard that "things be stored upwards in memory",
I meant inside arrays and as arguments passed to a function (on the stack,
usually).  If things were not stored that way, we wouldn't be talking
about incrementing a pointer as adding sizeof(...) to the address!

In the case where the "things" are of different types, as in the arguments-
on-the-stack case, their position must anyway be adjusted to fit the
alignment requirements of each type.  I gave the example of pushing a byte
on the stack on the 68000: a word (two bytes) is pushed to preserve
the even-ness of the stack pointer.  This could allow some reasonable
way to do "varargs".  It can also cause problems:  adding sizeof(char)
to a pointer used to access the stacked stuff will NOT work right on
the 68000, due to the above-mentioned automatic alignment.  This may
or may not be related to K&R introducing the automatic cast into an int
for calculations (and function calls) involving chars...

(If it still doesn't make any sense to you, Mike, it's YOUR problem :-)

- Moshe Braner