> I have little problem with revealing broken software.  NetBSD has already
> made it clear that it's a designed system, not an end-user system.  :)

but, it shouldn't be explicitly _designed_ to _not_ be an end-user
system.


> Also, AFAIK, if we use 32-bit int, and 64-bit long, the only place
> casting pointers to integers will fail will be a 64-bit pointer environment.

... or, if you look at it the other way, casting pointers to longs
(the way it's done now), will break on all 32-bit systems.

of course, if you fix the size of int and long to 32- and 64-bits,
respectively:
	(1) you're going to lose as machines move to 64-bits.  in
	    not _that_ long, there will be desktop machines on which
	    32-bit ops _are_ more espensive than 64-bit ops.  "what
	    do you do then?"  (That's already a problem on e.g.
	    the cray, but there it's not '64', it's another weird
	    number.)
	(2) you're going to lose when 128 bit systems come around.
	    It will happen eventually, and NetBSD may even be
	    around when it does.  You thought the 32->64 transition
	    was hard?  doing something like this would be a _total_
	    screw; you'd have to undo it, and redo it all again
	    differently, to get a working system.

"why engineer obsolescence into the software?"  It's not like we're
getting paid for upgrades, or anything.


cgd