[M3commit] CVS Update: cm3

Jay Krell jkrell at elego.de
Thu Apr 15 13:44:28 CEST 2010


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.




More information about the M3commit mailing list