Date: Mon, 02 Sep 2002 18:31:25 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current Message-ID: <3D7410ED.ED1D4090@mindspring.com> References: <20020902215358.E3A992A893@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
> Matthew Dillon wrote:
> > :4) Changing time_t to 64 bit using long long on a native 32 bit platform
> > :is a f*cking nightmare. I've tried this and it got very nasty very quickly.
> >
> > This is not what I proposed. I proposed adding new system calls to
> > completely and permanently fix all of our outstanding issues and then
> > providing a compiler option to allow developers to select which API
> > they want presented.
>
> Well, one thing that I would not be against is a clean divorce of the
> syscall layer and libc. That then gives us the freedom to implement
> alternative API selections etc at compile time pretty easily.
I was really, really tempted to suggest this, but I couldn't
come up with a way to make it work as a shared interface under
a single libc, without doing the fixup in the crt0 ala the
dlopen fixup for use of code in the ld.so (and have different
crt0/ld.so's). The 32 bit versions could be stubbed to the 64's
in the stub code, right there, which would make the system calls
DTRT on both platforms.
The other downside appears to be that the only way to do this
entirely cleanly is to give up on the static linking support,
so that the lib-linked-with-lib works per the ELF specification,
which is a real bikeshed. 8-(.
> I just really do not want to see this sort of thing turning up:
>
> time_t foo = time(0);
> printf("the time is %lld\n", (long long)foo); /* i386 compatability */
>
> .. because that hurts our 64 bit platforms down the road when long long
> becomes 128 bit. intmax_t/%j etc has similar problems as it then takes
> the native 64 bit time type (long) and converts it to a synthetic 128 bit
> type. ie: %j and intmax_t etc are just as bad.
I think the issue comes down to running 32 bit code on 64 bit
platforms, particularly, Intel code, and having it "just work".
I don't know how to avoid the problem, without adding sizing
to the types (e.g. "time64_t").
This is a very tempting thing to do; that changes your code
into:
time64_t foo = time64(0);
printf("the time is %lld\n", foo);
Or:
time_t foo = time(0);
printf("the time is %ld\n", foo); /* WARNING */
I think that the argument comes down to internal use of 64 bit
types on 32 bit platforms, with the 64/32 conversion done at
the system call interface.
PHK's right: POSIX sucks.
> My first exposure to a unix OS had some pretty horrific stat structure
> versioning and evilness (svr4). It was a real nightmare, except you never
> got to wake up and discover that it was all over.
>
> I am not against providing 64 bit extentions for 32 bit systems, but it
> really needs to be done so that it all becomes a giant NOP when on native
> 64 bit systems. Something like the large-file-summit API extensions that
> all magically go away after the transition period or when you get a chance
> to do a total ABI breakaway.
The real problem in the example is printf; it's because there's
a sized integer type specifier in the format string, instead of
an unsized one, and the compiler whines about this. That's what
will end up making the code different on a 32 bit machine, no
matter what. 8-(.
Maybe in this case, GCC has gotten too smart for it's own good?
IMO, for a long time now, POSIX has belonged in a "libposix",
which is built on top of the native system services, but that's
*really* a lot to ask...
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D7410ED.ED1D4090>