incrementing after a cast

Karl Heuer karl at haddock.UUCP
Wed Dec 10 14:29:24 AEST 1986


In article <1746 at batcomputer.tn.cornell.edu> braner at batcomputer.UUCP (braner) writes:
>[when using the (illegal) expression ((sometype *)pointer)++,] some machines
>supposedly give you problems.  But the implementations should avoid problems
>by agreeing that: ... casting to a pointer to a type with stricter alignment
>will be rounded UP to fit.

No.  If the machine has to do extra work to guarantee proper alignment, then
I don't want it done.  (In *my* code, (sometype *)charpointer only appears
if I already know charpointer is aligned.)

>(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.)

I don't think this is relevant.  If the architecture requires (or the compiler
prefers) the stack pointer to always be aligned, then push(byte) may have to
be compiled into movb(byte, *--sp) and clrb(*--sp), but here the adjustment is
by a constant amount known at compile-time.

>As for recycling registers, using the same register for different
>types in the same function:  I think that would be very valuable.
>How about allowing something like this:
>	register union {int i; long j;} x;

As far as I know, this is legal C.  However, many (most?) compilers don't
believe that a struct/union can fit in a register*, and will treat it as
"auto"; on such a machine you sacrifice both readability and efficiency.

I try to declare register variables in the smallest possible scope, but
sometimes the lexical scopes still overlap even though the useful lifespans
do not.  If I'm really concerned about efficiency, I'll hand-optimize the
asm file.

I predict there will never be an official extension to C to "fix" this.
Some compilers already optimize register usage; soon this will be expected
behavior, and the "register" keyword will be obsolete.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
*It would be nice if more compilers would make a special case out of "small
struct/union".  In particular, a function returning union{int;char*} should
not have to use the general "hidden fake arg" mechanism.



More information about the Comp.lang.c mailing list