As I imagine most of tech-toolchain is rather tired of this
logic-chopping, I'll restrict myself (on-list, at least) to the
fragments that have at least some relevance to gcc 3.3 and/or NetBSD.

>> A compiler could, for example, document [...].  That would satisfy
>> the documentation requirement and still permit allocating one member
>> in a register and another in memory.
> In theory, sure.  In practice, such a compiler would not be used, so
> it doesn't seem worth worrying about.

Well, I would have said the same thing ("would not be used") about a
compiler that broke the pointer-casting version that started this whole
thread off.  I have no problem imagining an (otherwise :-) useful
compiler at some high level of optimization moving one member of a
union into a register and leaving another in memory.  It would break
one of the common uses of unions, yes, but then, the pointer-cast issue
that started us off breaks one of the common uses of pointer casting;
the gcc people are obviously not afraid to break traditional tricks in
the name of better optimization.

> Yes.  But since type punning is an essential part of C, and gcc is
> explicitly documenting a form of type punning which works, I think it
> is quite unlikely to change.

Perhaps not.  But even if not, that's not much use in practice unless
either you're willing to commit to gcc or other compilers follow suit;
for example, I could easily imagine a magic keyword (__pun__, say) that
when written between a cast and the casted rvalue causes the cast to
function as a type pun...it's the same problem as depending on any
compiler-specific property (including the one you point out gcc
documents itself as supporting).

As for what NetBSD should do...well, perhaps type-puns should be
wrapped in a macro.  For gcc, that macro could be something like

#define TYPEPUN(val,newtype) (((union { newtype __a; __typeof__((val)) __b; }){__b:(val)}).__a)

and for pointer-cast-using compilers it'd be just

#define TYPEPUN(val,newtype) (*(newtype *)&(val))

Then at least there'd be only one thing to change, instead of umpteen
zillion type puns scattered all over, when anyone has cause to switch
type-punning paradigms (eg, building under non-gcc, or under some new
gcc, or whatever).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B