[M3devel] fyi Utime.i3 / UtimeExtra.i3

[Jay]

Are localtime_r and gmtime_r really not widely available these days?
  I don't have a Darwin system handy this week.
 
That is, we have DateBsd.m3, DateLinux.m3, DatePosix.m3.
Excerpt:
 
readonly _DateImpls = {
  "AMD64_DARWIN": "DateBsd",
  "AMD64_LINUX": "DateBsd",
  "FreeBSD*"    : "DateBsd",
  "LINUXLIBC6" : "DateBsd",
  "MIPS64_OPENBSD" : "DateBsd",
  "NT386"      : "DateLinux",
  "NT386GNU"   : "DateLinux",
  "SOLgnu"     : "DatePosix",
  "SOLsun"     : "DatePosix",
  "SPARC"      : "DateBsd",
  "*_LINUX" : "DateBsd",
  "SPARC64_SOLARIS" : "DatePosix",
  "*_DARWIN" : "DateBsd",
  "*_OPENBSD" : "DateBsd",
}
 
DateLinux lacks reentreent functions, and lacks gmtoff/zone in struct tm.
  It is only used by Cygwin. And Linux 1.x which I assume doesn't matter.
  This appears to be an oversight by me, the reentrant functions exist.
 
DateBsd lacks reentrant functions, and has gmtoff/zone in struct tm.
  It is very widely used.
 
DatePosix has reentrant functions, and lacks gmtoff/zone in struct tm.
 
I rather suspect that everyone can just use DatePosix.
?
Or at least that DateBsd can use reentrant functions.
Eliminating unnecessary locks/globals always seems good.
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Sat, 27 Dec 2008 19:48:46 +0000
> Subject: [M3devel] fyi Utime.i3 / UtimeExtra.i3
>
>
> fyi:
>
>
> I've been looking at Utime.i3.
> One of the variations is whether or not struct_tm contains gmtoff and zone at the end.
>
>
> C:\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3
> C:\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3
>
>
> are wrong on some systems.
> They unconditionally add the two fields, and read from memory that doesn't necessarily have them.
>
>
> It is ok on FreeBSD, OpenBSD, NetBSD, modern Linux (maybe not Linux 1.x), Darwin.
> It appears wrong on Cygwin, Solaris, HP-UX, Irix, OS/2 (did OS/2 ever work?).
> I'll double check Solaris and Irix soon or next week.
>
>
> I'll try to come up with a fix shortly.
> It will surely involve deleting those two files.
> And breaking any users of Utime.localtime and Utime.gmtime.
>
>
> - Jay