[M3commit] CVS Update: cm3

[Jay K]

diff attached

 
> Date: Thu, 15 Apr 2010 13:44:28 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/04/15 13:44:28
> 
> Modified files:
> cm3/m3-libs/m3core/src/: m3core.h 
> cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c 
> TimePosix.i3 TimePosix.m3 
> TimePosixC.c m3makefile 
> cm3/m3-libs/m3core/src/unix/: m3makefile 
> cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c 
> Utypes.i3 
> Added files:
> cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 
> 
> Log message:
> eliminate struct_tm (somewhat platform specific)
> eliminate struct_timeval (somewhat platform specific)
> eliminate FDSet (somewhat platform specific)
> eliminate MAX_FDSET (somewhat platform specific)
> eliminate lots of functions from Utime
> i.e. functions that use those types, like gettimeofday, localtime, gmtime
> functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone
> 
> eliminate "all" the m3core/src/unix platform dependent directories *except*
> Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support
> uin-common vs. uin-len
> 
> change time_t to be 64bits for all platforms
> but underlying implementation still needs work (elaborated below)
> 
> tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6
> It compiles and the assertions all hold.
> Local and utc data appears correct, cross checking with date and date -u, including
> setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010.
> Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code).
> 
> still to do:
> use 64bit time_t code from http://code.google.com/p/y2038/
> combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions
> We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t,
> as long as we use our own carefully controlled/copied types (i.e. omit the
> extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must.
> Maybe test on Darwin, *BSD, Cygwin, Interix, etc.
> Test in other timezones.
> Enable a regularly run test?
> Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere.
> (Hard to avoid if there are subranges, will be padded at least at end.)
> 
> We can't achieve 64bit gettimeofday or file timestamps beyond year 2038
> but if you fill in a Date.T with year > 2038, that can be useful and be made
> to work. It should roundtrip with Time.T and be printable.
> 
> structure is a little odd
> DatePosix.i3, TimePosix.i3 describe C code
> DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix
> This is just to reuse existing names or name patterns.
> We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc.
> 
> Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken.
> 
> Note: This also uncovered that my Solaris clock was behind by a few minutes.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100415/4eaa491d/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100415/4eaa491d/attachment-0002.txt>