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!

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

At Tue, 27 Jul 2004 20:52:39 +0000 (UTC), Alan Coopersmith <alanc@alum.calbe
rkeley.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
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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

At Wed, 28 Jul 2004 04:18:51 +0000 (UTC), Alan Coopersmith <alanc@alum.calbe
rkeley.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....

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]