Re: [Bug-gnulib] new module: timegm

[Paul Eggert]

Simon Josefsson <address@hidden> writes:

> I want my library to be thread safe.

Fair enough.  I played software archaeologist for a while, and found the
following problems:

 (1) In many implementations, gmtime_r isn't visible unless you enable
     extensions, e.g., __EXTENSIONS__ in Solaris.

 (2) POSIX didn't standardize gmtime_r until the late 90s (don't know
     when exactly, but I suspect 1996 or 1998, in a threads module
     that was not merged into the full standard until late 2001).
     Before the standard came out, several vendors (including HP-UX
     and Digital Unix) had gmtime_r implementations that returned int
     (-1 on failure, 0 on success), not struct tm *.  Given the dates
     this is probably still worth worrying about.

 (3) Solaris localtime_r has had many bugs reported for it over the
     years.  I think this is because it is a new implementation, that
     attempts to be high-performance for multithreaded apps.  For
     example, Sun bug 4162491 says that localtime_r fails on extreme
     timestamp values; this bug was fixed in Sun patch 103640-31 (for
     Solaris 2.5.1 sparc).  The most recent bugs (e.g., 4155856,
     4308809) are not visible to outsiders like me, even outsiders
     with software support, so I assume they're security relevant bugs
     that have not been fixed yet (they appear to be buffer overruns).
     I assume gmtime_r is similar, though it has fewer bugs reported
     against it.

     (My favorite bug report in the area was 4782294 "localtime_r is
     slow on Solaris when compared to Linux".  Filed in April 2003; a
     fix is supposed to appear in Solaris 10.  Solaris mktime is also
     dozens of time slower than glibc mktime, which in turn is a tad
     slower than gnulib mktime.  :-)

I'll work on a solution that solves (1) by enabling extensions, that
solves (2) by not using gmtime_r in the nonstandard implementations,
and that solves (3) by assuming Solaris users have installed the
appropriate patches (which don't exist yet!) and/or the bugs occur
only in multithreaded apps (which is good enough for me).

I suppose I should fix the other modules that use localtime and
gmtime, e.g., strftime, mktime, posixtm.  Perhaps the most
straightforward approach is to define a new module "time_r" that
defines a working localtime_r and gmtime_r (and ctime_r etc. too, if
they're needed).