Home > Archive > Unix Programming > July 2004 > In which Solaris version 'typedef long long time_t;' ??
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
In which Solaris version 'typedef long long time_t;' ??
|
|
| qazmlp 2004-07-28, 9:05 pm |
| This is an excerpt from the header file existing in Solaris system.
460 typedef long time_t; /* time of day in seconds */
The systems which use this header will face 2038 problem sinch time_t
will be used to hold the time values throughout the program. As I
understand, redefining the typedef as
460 typedef long long time_t; /* time of day in seconds */
should solve this problem.
I would like to know whether new versions of the Solaris systems have
this definition already. If yes, kindly give the information about
exactly in which version, this change was made.
Thanks!
| |
| Rich Teer 2004-07-28, 9:05 pm |
| On Tue, 27 Jul 2004, qazmlp wrote:
> This is an excerpt from the header file existing in Solaris system.
> 460 typedef long time_t; /* time of day in seconds */
>
> The systems which use this header will face 2038 problem sinch time_t
> will be used to hold the time values throughout the program. As I
> understand, redefining the typedef as
> 460 typedef long long time_t; /* time of day in seconds */
> should solve this problem.
Do NOT do this. The correct way to solve your problem is to
compile your program as a 64-bit application.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Alan Coopersmith 2004-07-28, 9:05 pm |
| qazmlp1209@rediffmail.com (qazmlp) writes in comp.unix.solaris:
|This is an excerpt from the header file existing in Solaris system.
|460 typedef long time_t; /* time of day in seconds */
|
|The systems which use this header will face 2038 problem sinch time_t
|will be used to hold the time values throughout the program. As I
|understand, redefining the typedef as
|460 typedef long long time_t; /* time of day in seconds */
|should solve this problem.
|
|I would like to know whether new versions of the Solaris systems have
|this definition already. If yes, kindly give the information about
|exactly in which version, this change was made.
That change can never be made, since it will break all existing
applications that were built with a 32-bit time_t. If 32-bit
applications are still in use in 2038, a transitional interface would be
needed like the 64-bit file offset API's, but most likely, everyone
will have recompiled in 64-bit mode by then, where the long expands to
64-bits automatically.
--
________________________________________
________________________________
Alan Coopersmith * alanc@alum.calberkeley.org * Alan.Coopersmith@Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
| |
| Paul Eggert 2004-07-28, 9:05 pm |
| At Tue, 27 Jul 2004 20:52:39 +0000 (UTC), Alan Coopersmith <alanc@alum.calberkeley.org> writes:
> If 32-bit applications are still in use in 2038, a transitional
> interface would be needed like the 64-bit file offset API's, but
> most likely, everyone will have recompiled in 64-bit mode by then,
> where the long expands to 64-bits automatically.
Well, no, actually the problem is biting us today. For example, as a
sy min I can't reliably use the 'find' command on Solaris 9 to look
for arbitrary files, since some joker or buggy program may have set a
file or directory's time stamp outside the 32-bit range.
Once Sun and everybody else is shipping and using only 64-bit
applications, this problem will be solved, but we're not there yet and
we won't be for many years. Until then, we have a problem, and it's
too bad that Sun hasn't yet seen fit to ship a transitional interface
for time_t.
| |
| Roland Mainz 2004-07-28, 9:05 pm |
| Paul Eggert wrote:
> Once Sun and everybody else is shipping and using only 64-bit
> applications, this problem will be solved, but we're not there yet and
> we won't be for many years. Until then, we have a problem, and it's
> too bad that Sun hasn't yet seen fit to ship a transitional interface
> for time_t.
Is there anywhere within SunSolve a RFE which requests such an interface
? Solaris 10 isn't out yet and it doesn't sound difficult to add such a
beast and make it the default for new 32bit applications... :)
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
| |
| Alan Coopersmith 2004-07-28, 9:05 pm |
| Roland Mainz <roland.mainz@nrubsig.org> writes in comp.unix.solaris:
|Paul Eggert wrote:
|> Once Sun and everybody else is shipping and using only 64-bit
|> applications, this problem will be solved, but we're not there yet and
|> we won't be for many years. Until then, we have a problem, and it's
|> too bad that Sun hasn't yet seen fit to ship a transitional interface
|> for time_t.
|
|Is there anywhere within SunSolve a RFE which requests such an interface?
4525289 Need 64bit API for time functions
--
________________________________________
________________________________
Alan Coopersmith * alanc@alum.calberkeley.org * Alan.Coopersmith@Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
| |
| Paul Eggert 2004-07-28, 9:05 pm |
| At Wed, 28 Jul 2004 04:18:51 +0000 (UTC), Alan Coopersmith <alanc@alum.calberkeley.org> writes:
> 4525289 Need 64bit API for time functions
Odd: that's not in the publicly accessable SunSolve database.
(Did you file that RFE yourself just now? :-)
Anyway, thanks for listening....
| |
| Alan Coopersmith 2004-07-28, 9:05 pm |
| Paul Eggert <eggert@twinsun.com> writes in comp.unix.solaris:
|<alanc@alum.calberkeley.org> writes:
|> 4525289 Need 64bit API for time functions
|
|Odd: that's not in the publicly accessable SunSolve database.
I believe RFE's generally are not visible in SunSolve. (Though part of
the ongoing planning around open sourcing Solaris includes thinking
about how public the bug database should be, so maybe that will change
in th future.)
|(Did you file that RFE yourself just now? :-)
Nope. A bug filed today would be in the 50xxxxx range somewhere.
(I'm not VPN'ed into Sun right now to check.)
--
________________________________________
________________________________
Alan Coopersmith * alanc@alum.calberkeley.org * Alan.Coopersmith@Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
| |
| Roland Mainz 2004-07-28, 9:05 pm |
| Alan Coopersmith wrote:
>
> Roland Mainz <roland.mainz@nrubsig.org> writes in comp.unix.solaris:
> |Paul Eggert wrote:
> |> Once Sun and everybody else is shipping and using only 64-bit
> |> applications, this problem will be solved, but we're not there yet and
> |> we won't be for many years. Until then, we have a problem, and it's
> |> too bad that Sun hasn't yet seen fit to ship a transitional interface
> |> for time_t.
> |
> |Is there anywhere within SunSolve a RFE which requests such an interface?
>
> 4525289 Need 64bit API for time functions
Nice... :)
.... now we need a victim at Sun who works on Solaris's libc and convince
him/her to implement that for S10... :)
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
| |
| Joerg Schilling 2004-07-28, 9:05 pm |
| In article <4107275D.C4EEB6DC@nrubsig.org>,
Roland Mainz <roland.mainz@nrubsig.org> wrote:
>Paul Eggert wrote:
>
>Is there anywhere within SunSolve a RFE which requests such an interface
>? Solaris 10 isn't out yet and it doesn't sound difficult to add such a
>beast and make it the default for new 32bit applications... :)
The problem these days is not really that there is no such interface
but that UFS supports time stamps from Dec 13th 1901 ... Jan 19th 2038
while NFS supports Jan 1st 1970 ... Feb 7th 2106 AND that NFS silently
maps Dec 31th 1969 to Feb 7th 2106.
You will never run into problems using 32 bit applications only for
local filesystems.
BTW: Solaris 10 already has feature freeze.....
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
| |
| Joerg Schilling 2004-07-28, 9:05 pm |
| In article <410750E6.7EC4A787@nrubsig.org>,
Roland Mainz <roland.mainz@nrubsig.org> wrote:
>
>Nice... :)
>
>... now we need a victim at Sun who works on Solaris's libc and convince
>him/her to implement that for S10... :)
1) Not before Solaris 10 Update #1
2) You first would need a new syscall....
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
| |
| Joerg Schilling 2004-07-28, 9:05 pm |
| In article <7wekmxkqv9.fsf@sic.twinsun.com>,
Paul Eggert <eggert@twinsun.com> wrote:
>At Tue, 27 Jul 2004 20:52:39 +0000 (UTC), Alan Coopersmith <alanc@alum.calberkeley.org> writes:
>
>
>Well, no, actually the problem is biting us today. For example, as a
>symin I can't reliably use the 'find' command on Solaris 9 to look
>for arbitrary files, since some joker or buggy program may have set a
>file or directory's time stamp outside the 32-bit range.
If you "only" need a POSIX.1-2001 compliant find program that works, you may
use "sfind". Sfind currently misses the POSIX -perm "symbolic mode" and
Sun's Solaris 9 -xattr Primary. If you don't need them, you may fetch
ftp://ftp.berlios.de/pub/sfind/sfind-0.93.tar.bz2
and call
make COPTX=-xarch=v9 LDOPTX=-xarch=v9
to compile a 64 bit version of the binary. Be careful when you use Sun's
make on Solaris 8 which does not propagate make macros to sub-make processes.
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
| |
| Paul Eggert 2004-07-28, 9:05 pm |
| At 28 Jul 2004 07:38:02 GMT, js@cs.tu-berlin.de (Joerg Schilling) writes:
> You will never run into problems using 32 bit applications only for
> local filesystems.
Yes I will, and I have. Here's a transcript showing a counterexample,
and illustrating the sort of disasters a Solaris symin can run into
in the presence of (shall we call them) pranksters. In this
transcript, the working directory contains copy of GNU coreutils 5.2.1
compiled in 64-bit mode. This example was run on 64-bit Solaris 9
sparc.
$ ./touch --date='1900-01-01' /tmp/ancient
$ ./ls -l /tmp/ancient
-rw-rw-r-- 1 eggert eggert 0 1900-01-01 00:00 /tmp/ancient
$ /bin/ls -l /tmp/ancient
/tmp/ancient: Value too large for defined data type
$ /bin/find /tmp -name '*.c' -print
/bin/find: cannot open /tmp: Value too large for defined data type
$ /bin/rm -f /tmp/ancient; echo $?
0
$ ./ls -l /tmp/ancient
-rw-rw-r-- 1 eggert eggert 0 1900-01-01 00:00 /tmp/ancient
Don't you just love "rm -f" silently exiting with status 0, even
though it failed to remove the file? Or that bogus diagnostic from
"find"?
I grant you that I run into the problem more often with NFS, due to
the usual problems with negative timestamps. (Fixed in NFSv4 I
think.)
The simplest workaround is to install GNU coreutils + findutils +
diffutils compiled in 64-bit mode, and prepend them to your path.
But Sun really oughta ship the standard utilities in 64-bit mode now.
This is not an RFE: it's a bug waiting to happen.
| |
| Roland Mainz 2004-07-28, 9:05 pm |
| Joerg Schilling wrote:
>
> The problem these days is not really that there is no such interface
> but that UFS supports time stamps from Dec 13th 1901 ... Jan 19th 2038
> while NFS supports Jan 1st 1970 ... Feb 7th 2106 AND that NFS silently
> maps Dec 31th 1969 to Feb 7th 2106.
What about NFSv4 ? DOes it still use 32bit integers for timestamps ?
> You will never run into problems using 32 bit applications only for
> local filesystems.
Sure, but it would still be nice to have a 64bit version of time_t. UFS
may not support it, but other filesystems like ZFS&co. will (hopefully)
support it...
> BTW: Solaris 10 already has feature freeze.....
;-((
----
Bye,
Roland
P.S.: Did someone fix "cron" to support "seconds" yet (e.g. start a job
at 17:52:35 (=35 secs after 17:52h) ?
--
__ . . __
(o.\ \/ /.o) roland.mainz@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
| |
| Joerg Schilling 2004-07-29, 8:57 am |
| In article <410829D7.50E65647@nrubsig.org>,
Roland Mainz <roland.mainz@nrubsig.org> wrote:
>
>What about NFSv4 ? DOes it still use 32bit integers for timestamps ?
>
>
>Sure, but it would still be nice to have a 64bit version of time_t. UFS
>may not support it, but other filesystems like ZFS&co. will (hopefully)
>support it...
As you might have seen already, Paul Eggert pointed to tmpfs which
already seems to support 64 bit time_t's.
For this reason and because Solaris 10 FCS will most likely include ZFS,
we definitely need a transitional interface for 64 bit time_t in 32 bit
processes.
Other OS (e.g. True-64 & Linux) even have this problem with their 64 bit
kernels ;-) For FreeBSD on Ultrasparc, I have been able to prevent a
broken 32 bit time_t in the last minute.
Note that True-64 is supposed to have an additional special interface for
a 64 bit time_t, so there is no big problem if Solaris does similar things.
>P.S.: Did someone fix "cron" to support "seconds" yet (e.g. start a job
>at 17:52:35 (=35 secs after 17:52h) ?
How, without violating POSIX?
http://www.opengroup.org/onlinepubs...es/crontab.html
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
| |
| Måns Rullgård 2004-07-29, 8:57 am |
| js@cs.tu-berlin.de (Joerg Schilling) writes:
> Other OS (e.g. True-64 & Linux) even have this problem with their 64 bit
> kernels ;-)
If one of my Alpha machines loses power for too long it resets the
clock to year 2051. All programs I ever use seem quite happy with
this under Linux.
--
Måns Rullgård
mru@kth.se
| |
| Joerg Schilling 2004-07-29, 8:57 am |
| In article <yw1x8yd3gmok.fsf@kth.se>,
=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@kth.se> wrote:
>js@cs.tu-berlin.de (Joerg Schilling) writes:
>
>
>If one of my Alpha machines loses power for too long it resets the
>clock to year 2051. All programs I ever use seem quite happy with
>this under Linux.
Maybe, they did change this during the past 2 years, but from my porting
experiences, I definitly know that before, Linux on Alpha was using a
32 bit time_t - it did create a lot of trouble.....
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
| |
| Måns Rullgård 2004-07-29, 8:57 am |
| js@cs.tu-berlin.de (Joerg Schilling) writes:
> In article <yw1x8yd3gmok.fsf@kth.se>,
> =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@kth.se> wrote:
>
> Maybe, they did change this during the past 2 years, but from my porting
> experiences, I definitly know that before, Linux on Alpha was using a
> 32 bit time_t - it did create a lot of trouble.....
Both glibc and Linux on my Alphas typedef time_t as a long, which is
64 bits. This is glibc 2.3 and Linux 2.6. AFAIK it has been this way
for a long time, at least since Linux 2.2 and glibc 2.1.
--
Måns Rullgård
mru@kth.se
| |
| Joerg Schilling 2004-07-29, 8:57 am |
| In article <yw1x4qnrgl1i.fsf@kth.se>,
=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@kth.se> wrote:
>
>Both glibc and Linux on my Alphas typedef time_t as a long, which is
>64 bits. This is glibc 2.3 and Linux 2.6. AFAIK it has been this way
>for a long time, at least since Linux 2.2 and glibc 2.1.
..... do you know that there is struct timeval?
Did you ever look into the definition on Linux?
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
| |
| Måns Rullgård 2004-07-29, 3:57 pm |
| js@cs.tu-berlin.de (Joerg Schilling) writes:
> In article <yw1x4qnrgl1i.fsf@kth.se>,
> =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@kth.se> wrote:
>
> .... do you know that there is struct timeval?
>
> Did you ever look into the definition on Linux?
Sure did. This fragment is from .../linux/include/linux/time.h:
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};
..../linux/include/linux/types.h defines time_t like this:
typedef __kernel_time_t time_t;
__kernel_time_t is defined in .../linux/include/asm/posix-types.h:
typedef long __kernel_time_t;
long is 64 bits on Alpha.
Where is the problem?
--
Måns Rullgård
mru@kth.se
| |
| Joerg Schilling 2004-07-29, 3:57 pm |
| In article <yw1xvfg6g7j0.fsf@kth.se>,
=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@kth.se> wrote:
>js@cs.tu-berlin.de (Joerg Schilling) writes:
>
>Sure did. This fragment is from .../linux/include/linux/time.h:
>
>struct timeval {
> time_t tv_sec; /* seconds */
> suseconds_t tv_usec; /* microseconds */
>};
>
>.../linux/include/linux/types.h defines time_t like this:
>
>typedef __kernel_time_t time_t;
>
>__kernel_time_t is defined in .../linux/include/asm/posix-types.h:
>
>typedef long __kernel_time_t;
>
>long is 64 bits on Alpha.
>
>Where is the problem?
2 years ago, it has been an int.
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
| |
| Måns Rullgård 2004-07-29, 3:57 pm |
| js@cs.tu-berlin.de (Joerg Schilling) writes:
> In article <yw1xvfg6g7j0.fsf@kth.se>,
> =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@kth.se> wrote:
>
>
> 2 years ago, it has been an int.
I was using Alphas at that time. I suppose I just was lucky.
--
Måns Rullgård
mru@kth.se
|
|
|
|
|