>> I that's the root of the problem: having -fstrict-aliasing on by
>> default for -O2.
> To me it seems like a culture clash.

I think you're both right, actually.

I now see it as a culture clash between what I might call "traditional"
C, going back to the days of pcc, where C earned the sobriquet of
"high-level assembly language", a language very well suited to its
original purpose of implementing a new OS...and what I might call "new"
C, which arose when someone looked at all the variants of C and tried
to boil away the machine differences and figure out what portion of the
language could actually be standardized.

Then, of course, since that common subset was a relatively restricted
subset, it became possible to build an implementation that broke
traditional assumptions (the "high-level assembly language" ones,
basically) and have something to point to as a defense when people, not
entirely unreasonably, started saying (from the traditional viewpoint)
"but that's not how C works".

Going down this road, I foresee a split between C the implementation
language ("traditional" C) and C the highish-level application language
("new" C).  From that point of view, the only problem here is that by
turning on -fstrict-alias with -O2, gcc has made one of two changes:
(1) they have switched from compiling traditional C to compiling new C,
or (2) they have lost the traditional property that turning on
optimization changes performance, not semantics.  Or more precisely,
that they have done so without being up-front about it.  (I suspect (1)
is closer to the truth, but I am not really in a position to more than
guess.)

This is admittedly a vague line of reasoning, and "reasoning" may not
even be entirely the correct word.  But I think that's where the upset
is coming from.

For NetBSD, this is a problem because NetBSD really wants both
traditional C (for things like the kernel) and new C (for applications
and much of userland and suchlike), and secondarily because if NetBSD
imports this new gcc unchanged, it will be inflicting on its users the
same silent and partial shift from traditional C to new C that I wrote
about above.

Perhaps that's OK with NetBSD.  But I think it's Not Good.

And in passing....

> At the risk of sounding condescending, I'll point out that it is, of
> course, possible to write the earlier example in a standard
> conforming fashion.

How?  I can't see any way short of allocating a struct in_addr and
copying.

/~\ 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