>> 		       inet_ntoa(*((struct in_addr *) &inet)));

> So what do you expact the dereference of the casted pointer to mean?
> Should it pass a 4 byte object to inet_ntoa (and which half of the 8
> byte object you started from)?

Yes.  The low half, the alpha being a little-endian architecture.

> Anyway, C99 does not allow such casts, [...]

> This is *not* a compiler bug.  According to the C standard you are
> invoking undefined behaviour.

That's fine as far as C goes.  But as far as I am concerned, gcc has
just over-standardized itself into irrelevance.  One of C's strong
points has always been that when you do something outside the bounds of
what the language promises, like the cast you quote, you get results
that are unsurprising to someone who knows the underlying machine.  It
appears gcc has broken that, and it means that it is now useless as a
language for things, like operating system implementations, where that
property is important.

I can understand C qua C making such casts implementation-specific
(which is what "undefined behaviour" really means in practice: you get
what the implementation happens to give you); not all machines have
memory addresses in the traditional sense to make such a thing
well-defined.  But for gcc to gratuitously break the "unsurprising to
someone familiar with the machine" property means it is no longer a
useful compiler for many of C's traditional uses.

I'm astonished and disappointed that NetBSD is importing such a
compiler, and I'm glad I won't be tracking it.

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