Re: x32 “half” arrived… now what?
On Tue, Jun 11, 2013 at 08:27:07PM -0500, Gunnar Wolf wrote:
> Chow Loong Jin dijo [Wed, Jun 12, 2013 at 08:40:11AM +0800]:
> > > > > 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--;
>
> I hope faith_in_humanity is not declared as unsigned, as you might
> have there an integer overflow (actually, underflow) waiting to happen.
And sizeof(long) = sizeof(void *) is by design in the spec. The only
OS that doesn't do that is windows 64bit, where sizeof(long long)
= sizeof(void *) and sizeof(long) = sizeof(int) because apparently
microsoft's own headers fucked it up so many places that there was just
no way to fix it apparently.
It is the LP64 model, where as windows is the LLP64 model.
--
Len Sorensn
Reply to: