Very Computer

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!

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

|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.

--
________________________________________________________________________

 http://www.csua.berkeley.edu/~alanc/   *   http://blogs.sun.com/alanc/
  Working for, but definitely not speaking for, Sun Microsystems, Inc.

Quote:> 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
sysadmin 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.

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

--
  __ .  . __

  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

|> 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

--
________________________________________________________________________

 http://www.csua.berkeley.edu/~alanc/   *   http://blogs.sun.com/alanc/
  Working for, but definitely not speaking for, Sun Microsystems, Inc.

Quote:> 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....

|> 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.)

--
________________________________________________________________________

 http://www.csua.berkeley.edu/~alanc/   *   http://blogs.sun.com/alanc/
  Working for, but definitely not speaking for, Sun Microsystems, Inc.

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

--
  __ .  . __

  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

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.....

--



URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Quote:>> 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... :)

1) Not before Solaris 10 Update #1

2) You first would need a new syscall....

--



URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

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.

--



URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Quote:> 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 sysadmin 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.

What about NFSv4 ? DOes it still use 32bit integers for timestamps ?

Quote:> 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...

Quote:> 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) ?

--
  __ .  . __

  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

Quote:>> 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...

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.

Quote:>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/009695399/utilities/crontab.html

--



URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily