Type punning in C
P E Smee
exspes at gdr.bath.ac.uk
Mon Oct 16 19:29:36 AEST 1989
In article <126279 at sun.Eng.Sun.COM> khb at sun.UUCP (Keith Bierman - SPD Advanced Languages) writes:
>In article <1989Oct11.091619.18336 at gdt.bath.ac.uk> exspes at gdr.bath.ac.uk (P E Smee) writes:
>
>
>>Problem is, the Fortran standard *also* says that if your program tries
>>to take the value of the variable using a different type than the type you
>>used when you last stored into it, your program is invalid.
>
>My quick peek into the document (pages 8-3 and 17-1..4ish) doesn't
>make this obvious to me. Could you please quote chapter and verse ?
>
Section 17.3(2) -- (or, page 17.4, lines 15-18) 'When an entity of a
given type becomes defined, all totally associated entities of
different type become undefined.' With 17.2(1) 'Execution of an
arithmetic, logical, or character assignment statement causes the
entity that precedes the equals to become defined. These must, of
course, be taken in conjunction with the definition of what it means
for something to be defined, and with the fact that if your program
uses variables while they are undefined, your program is invalid.
>From 17.1 it is clear that EQUIVALENCE may cause total association.
May also cause only partial association depending on what the
equivalanced entities are. In particular, from 17.1.1 single
(non-array) integer, real, and logical values equivalenced in any mix
are totally associated.
>>
>>Fortran equivalence was designed toallow reuse of storage on the early
>>small memory machines -- not to allow type punning. Usually you can
>>get away with punning, but it doesn't always work and so is a bad habit.
>>
>
>On which systems (if any) have you seen this not work ?
>
Honeywell Multics at certain optimisation levels. Of course, since HIS
don't make them any more, that's a moot point. I believe I recall
similar occasional problems under various flavours of IBM OSes, again
at particular optimisation levels. Doesn't alter the fact that since
the standard makes it clear that it can be invalid, it's a bad habit.
--
Paul Smee | JANET: Smee at uk.ac.bristol
Computer Centre | BITNET: Smee%uk.ac.bristol at ukacrl.bitnet
University of Bristol | Internet: Smee%uk.ac.bristol at nsfnet-relay.ac.uk
(Phone: +44 272 303132) | UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes
More information about the Comp.lang.c
mailing list