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 - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
