Adam Borowski <kilob...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hahb9dfc....@windlord.stanford.edu
