> > In both cases, this _particular_ example wouldn't normally cause
> > problems on either the Alpha or the ARM (even with a non-hacked
> > compiler).
> 
> good.  that's what i thought.
> 
> > However, knowing a bit about the wonderful proliferation of wacky CPU
> > architectures, I've no doubt that there's a system somewhere that it'd
> > break.  8-)
> 
> i don't think cpu architectures that break C portability will make much of
> an impression in the marketplace in the next dozen years.

uh, requiring structures to be aligned in a certain way doesn't break
C portability.  It might break "portability" of code which cannot be
implemented in portable C, but that's not _really_ portable code, is
it?


> > There's no reason to do it in 'committed' code, so why do it?
> 
> sure there is.  opaqueness has lasting value -- i disagree that this is
> just a lint question.  "struct in_addr" is still a struct and it keeps
> people from comparing addresses as if they were integers.  that opacity
> has kept a huge amount of bad code from being written over the years.

If you truly believe that, then you must agree that the struct-ness of
dev_t should be exported to user-land as well.  _that's_ my
disagreement with it being handles as described.  It should be the
same in user-land as it is in the kernel, alwasy.

That would solve any kernel vs. user-land binary incompatibility
problems.  However, I don't know if that's allowed by various
standards.



cgd