incrementing after a cast

[Mike McNally]

In article <1746 at batcomputer.tn.cornell.edu> braner at batcomputer.UUCP (braner) writes:
>[]
>
>If  ((sometype *)pointer)++ is not legal, then the law should be changed!
>(since the pointer-type cast is legal, why can't you use the resulting
>pointer like any pointer of sometype?)
>

You can use the pointer like any other pointer *value*.  However, as
with any construction resulting in an rvalue, the result of a cast
cannot be autoincremented; it has no address.  As many have pointed out
in this group over the past couple of months, on many machines the
casting of one pointer type to another requires that the value be
modified in some way.

>BUT, if you cast it back, as in varargs with args of various types,
>then some machines supposedly give you problems.  But the implementations
>should avoid problems by agreeing that:
>
>	consecutive things are stored upwards in memory,

What??  What if the "things" are of different types, and the
architecture of the machine favors storage of different types in
different segments?  What other high-level language guarantees that
separately-declared objects are stored consecutively? (I *know* that
dozens of people know of dozens of languages for which such assumptions
are valid; I don't want to hear about it.)

>	incrementing a pointer points to the next memory slot,

What is a memory slot?  In the language I use, C, when a pointer is
incremented, it is incremented;  afterwards it points to whatever it
points to.  The amount by which the pointer is incremented is equal to
the size of the type pointed to.  I guess I must be confused.

>	casting to a pointer to a type with stricter alignment
>	will be rounded UP to fit.  (This has to be done anyway
>	when figuring out how to store the stuff.  For example,
>	if you push a byte on the 68000 stack a whole word is used.)
>

Rounded UP?  Why not down?  Then, if I cast a pointer-to-char into a
pointer-to-long, the long will contain the char.  Actually, I don't
think any rounding should be done.  The semantics would be too machine-
dependent to be of any use in a program.  What would it mean anyway?
This is too bizarre for me.

>	[stuff about register variables]
>- Moshe Braner

I think that further suggestions along the lines of "let's change the
language so I can do something disallowed for good reason in the
existing language" should be directed to the ANSI committee, where they
hopefully will be directed to the ANSI wastebasket.

-- 
****                                                         ****
**** At Digital Lynx, we're almost in Garland, but not quite ****
****                                                         ****

Mike McNally                                    Digital Lynx Inc.
Software (not hardware) Person                  Dallas  TX  75243
uucp: ...convex!ctvax!bobkat!m5                 (214) 238-7474