Re: x32 “half” arrived… now what?
Adam Borowski <kilobyte@angband.pl> writes:
> On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote:
>> It's not quite as bad as the porting required for large file support,
>> but the consequences of not porting are worse.
> How come? I don't think runtime bugs that are not some kind of a Y2k38
> bug are likely, and unlike i386 and the rest, they're actually fixable
> now.
Because when you store a 64-bit quantity in a 32-bit hole, the result is
very frequently a security vulnerability or a runtime crash, and when you
assume 64 bits of data on the stack is actually 32 bits, you get
corruption when you read the next item on the stack. Consider stdargs
functions that pass in a time_t and read back a long, or programs that use
pointers to time_t and pointers to long interchangeably.
If it were just data truncation, I would agree with you, and that's the
case when the compiler knows all of the types involved and can do implicit
or explicit casts. But the C type system has a ton of holes in them (in
fact, implementing generic data structures generally requires punching
holes in the type system), at which point the exact number of bits
matters, and a lot of code has been written assuming sizeof(time_t) ==
sizeof(long).
I agree that assumption is *wrong*, and it looks like NetBSD is ahead of
us here and may be flushing out some of the problems already, but expect
to find a lot of broken code.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: