incrementing after a cast

[Bob Larson]

In article <1706 at batcomputer.tn.cornell.edu> garry%cadif-oak at cu-arpa.cs.cornell.edu writes:
>This was some discussion on the net a few months about whether this ought
>to be legitimate.  The context I would use it in is trying to recycle
>"valuable" register variables to point to different things during the life
>of a routine. For example, if I happen to know that A and B never overlap
>during execution, and that my machine only has 1 available-to-C register,
>I might want to do:
>
>	    ...
>	    register	char	*A;
>#           define	B	((float *)A)
>	    ...
>
>and expect both *A++ and *B++ to work and to be in registers for me. If
>I know that a pointer and an int take the same space and instructions on
>my machine I might also want to get away with:
>
>	    register	char	*A;
>#	    define	B	((int)A)
>	    ...
>	    ... *A++; ...
>	    ...
>	    ... B = 27;
>
>Unfortunately, that's not the way things stand on any compiler I have access
>to - your compiler must be exceptionally forgiving.

I'm glad none of the compilers I use allow such illegal constructs.
If you are realy that worried about register usage, I know of at least
two solutions that are leagal C and do not break on compilers that
don't support them:

1.  A compiler which does it's own register assignment based on the
code and ignores the "register" advisory on declarations.  Yes, I realy
do use such a compiler:  Prime C 5.0-19.4 with the -32ix and -optimize
1 options and no -noignoreregister option.  (Yes, the
-noignoreregister option does what you expect, it just produces worse
code in the majority of cases.)

2.  A compiler that properly supports declareation scopes, (I'm sure
there are some that don't, but how common it is I don't know) and
writing the code like:

	    ...
	    {
		register	char	*A;
		...
	    }
	    {
	    	register	float	*B;
		...
	    }
	    ...

Any reasonable compiler should use the same register for A and B iff
apropriate.  This also works in the case of int B, however the same
register will not be used if it is not appropriate.  (i.e. on a 68000
compiler that uses address registers for register pointer variables
and data registers for register int variables.)  Unless your compiler
is broken, this code will work even if the compiler isn't reasonable.

>I think the new spec doesn't disturb the status quo.

As much as possible, the ANSI C proposed standard tries to avoid
making such clearly non-portable code legal.  I wish they had also
made the type of quoted strings const char [] rather than char [], but
I do realize this would break some (in my optionion questionable) code.
The Prime C compiler has options to force this, but the os9/68k
compiler realy needs it.

>garry wiegand   (garry%cadif-oak at cu-arpa.cs.cornell.edu)


-- 
Bob Larson
Arpa: blarson at usc-oberon.arpa	or	Blarson at Usc-Eclb.Arpa
Uucp: (several backbone sites)!sdcrdcf!usc-oberon!blarson
			seismo!cit-vax!usc-oberon!blarson