mveao@cbnews.ATT.COM (eric.a.olson) (09/07/89)
>>> What if x is in a register?
Yeah. What if? I realize that registers might not have an
adress that can be taken, but why should that make taking its
address illegal rather than implementation-dependent?
I thought that 'register' storage class was supposed to be used
as a hint to the compiler that the variable would be heavily used and to
put it in a register if possible. This concept is not *necessarily*
at conflict with 'please take the address of this variable'.
eric olson
eao@mvuxq.att.comfieland@hobbiton.prime.com (09/09/89)
This problem has nothing to do with i being a register variable. The order of evaluation of the assignment and the increment of i in line 11 is undefined. The Sun compiler has done the assignment first when i is a register variable, and the increment first when it is not. This differs from compiler to compiler. The Mips compiler seems to always do the assignment first. Lint will very nicely print a warning about undefined evaluation order when you run it on this program. Peggy
ray@philmtl.philips.ca (Raymond Dunn) (09/09/89)
In article <9389@cbnews.ATT.COM> mveao@cbnews.ATT.COM (eric.a.olson,54242,wi,1f018,508 374 5626) writes: >>>> What if x is in a register? > >Yeah. What if? I realize that registers might not have an >adress that can be taken, but why should that make taking its >address illegal rather than implementation-dependent? Because the Language Reference specifically says it is illegal (even though it is sensible on many architectures where registers map to memory locations). -- Ray Dunn. | UUCP: ..!uunet!philmtl!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090