Date: Mon, 02 Sep 2002 14:53:58 -0700 From: Peter Wemm <peter@wemm.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current Message-ID: <20020902215358.E3A992A893@canning.wemm.org> In-Reply-To: <200209022104.g82L4mdf033101@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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.
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.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?20020902215358.E3A992A893>
