On Tue, Jun 11, 2013 at 10:36:48PM +0100, Ben Hutchings wrote: > On Tue, 2013-06-11 at 21:04 +0100, Roger Lynn wrote: > > On 06/06/13 21:10, Adam Borowski wrote: > > > On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: > > >> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect > > >> SUBSTANTIAL porting of packages to be required. Particularly since that > > >> arrangement is explicitly unsupported by the GNU coding standards: > > >> > > >> Similarly, don't make any effort to cater to the possibility that > > >> `long' will be smaller than predefined types like `size_t'. > > > > > > It was the case in old versions of gnulib, but appears to be no more. > > > Too bad, quite a few packages ship embedded copies of ancient gnulib. > > > I just submitted a patch in one such case (#711412), it might possibly > > > apply elsewhere. > > > > > > It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 > > > bug even if its word size is 32 bit, and I'd say he's right. This means > > > that this problem will bite us the next time another 32 bit arch comes, > > > so there's no excuse to use this as an argument against x32. > > > > Would a better solution not have been to make long 64 bits? This is a > > perfectly reasonable thing to do on a 32 bit arch, it would avoid the above > > problem and since the widespread adoption of 64 bit systems most of the > > cases of software expecting long to be 32 bits should have been fixed. > > sizeof(long) != sizeof(void *) will break *lots* of code. Odd, you'd have thought that people would have learnt from their mistakes after fixing their sizeof(int) == sizeof(void*) assumptions. faith_in_humanity--; -- Kind regards, Loong Jin
Attachment:
signature.asc
Description: Digital signature