[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: x32 “half” arrived… now what?



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.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: