In which Solaris version 'typedef long long time_t;' ??

In which Solaris version 'typedef long long time_t;' ??

Post by qazm » Thu, 29 Jul 2004 01:25:03



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!

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Rich Tee » Thu, 29 Jul 2004 02:10:14



> 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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Alan Coopersmit » Thu, 29 Jul 2004 05:52:39



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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Paul Egger » Thu, 29 Jul 2004 07:49:30



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.

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Roland Main » Thu, 29 Jul 2004 13:11:09



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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Alan Coopersmit » Thu, 29 Jul 2004 13:18:51



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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Paul Egger » Thu, 29 Jul 2004 13:40:42



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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Alan Coopersmit » Thu, 29 Jul 2004 15:37:10



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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Roland Main » Thu, 29 Jul 2004 16:08:22





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

--
  __ .  . __

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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Joerg Schilli » Thu, 29 Jul 2004 16:38:02





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

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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Joerg Schilli » Thu, 29 Jul 2004 16:41:25




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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Joerg Schilli » Thu, 29 Jul 2004 20:42:22





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

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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Paul Egger » Fri, 30 Jul 2004 05:39:53



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.

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Roland Main » Fri, 30 Jul 2004 07:33:59



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

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

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

 
 
 

In which Solaris version 'typedef long long time_t;' ??

Post by Joerg Schilli » Fri, 30 Jul 2004 18:50:14




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

 
 
 

1. why can't long long be 128 bits?

Why can't long long be 128 bits in 64 bit architectures?  It is
certainly the case that in 32 bit architectures it is generally
64 bits, even when that CPU has no 64 bit instructions, it being
emulated by compiled code.  So why not emulate 128 bit using 64
bit instructions?

Is long long going to end up being used in any syscalls now that
it is an available standard in C99 (not that Linux syscalls would
need to require C99).  If for some platform long is 64 bits, I
would think that any syscall that needs 64 bits could simply use
type long by defining whatever special type name to long or some
other type that is the right size.

I do know that a lot of C code around has assumed long is 32 bits
to the extreme of breaking if it is more.  Has such assumption
also been made that long long is exactly 64 bits and not more?

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------

2. Setting up IPv6 on Redhat 9.x

3. printf format specifier for `long long'

4. how to use ethereal to monitor localhost ????

5. long long & long double types in Linux GCC

6. Netscape 3.01 + Java + RH40 Crashing

7. RH7.2 2.4.X off_t: long or long long?

8. Blocking traceroutes at firewall level

9. very long timeouts on 'nfs' or 'amd' init during boots

10. Linux has a long, long, long way to go

11. External 'time_t' variable 'altzone' seems to be wrong !

12. long long int on Solaris 9223372036854775807

13. how does one tell 'man' how long a page is?