>>> It might be "useful" to you, but it's just flat out wrong for
>>> portable code, especially of course if you're using bitfields,
>> [...]
>>> They do go on to warn that an implementation need not permit such
>>> use of the null pointer constant in that fashion, but I've never
>>> encountered a compiler implementation that disallowed it.....
>> Does anyone else see the irony [...]
> I'm not sure I do....  I was referring to non-Unix compilers i've
> used in the past too, BTW.

...so?  Deriding one thing that compilers are extremely unlikely to
break as "flat out wrong for portable code", especially without any
reason cited to think any compilers that break it exist, and then in
the next breath defending another nonportability as "I've never
encountered a compiler [that broke it]" just seems so...so...well,
ironic.

>> Especially since "map[ping] over device register[s]" is
>> approximately the last place you have to worry about portability to
>> every compiler on the planet?
> That's certainly not true for NetBSD's kernel source tree.

Huh?  NetBSD expects to run on hardware with power-of-two wordsizes,
MMUs, and an addressing architecture that more or less amounts to an
MMU in front of a big array of bytes.  It doesn't have to deal,
especially in the kernel, with the sort of really unusual compilers
that are most likely to break tricky code, like the C compiler for the
Lisp Machine that I once heard of (but, alas, never actually saw).

> There are many device drivers which are portable between computers
> and which presumably should be maintained in such a way that they're
> also portable between compilers

Portability is not an all-or-nothing thing.  If you're accessing device
registers on an SBus card, for example, it's probably safe - and
certainly not unreasonable - to assume you're on a byte-addressed
machine...even though code making such an assumption is "nonportable",
and in a sufficiently wider context could be justly flamed for it.
Much of NetBSD, for example, assumes that 8-bit, 16-bit and 32-bit
types are available.  Some of this code assumes only that they're
at-least-8-bit, at-least-16-bit, etc, but I think I've seen some that
assumes they're exactly that size.  This will break badly if anyone
tries to port it to (say) a 36-bit machine.  (ISTR hearing of a nascent
NetBSD/pdp10 effort; wasn't the 10 a 36-bit machine?)

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