[Bug-xorriso] Re: Portability issues of xorriso on Solaris 9

[Thomas Schmitt]

Hi,

i evaluated three alternatives as workaround for timegm().

-------------------------------------------------------------------------

Your timegm() and the one of my Linux produce the same time_t values from
the same input. I tested with 1 million values between now and nearly 1970.

But i expected that timegm() resp. mktime() account for leap seconds.
(http://en.wikipedia.org/wiki/Leap_second)
Yours obviously does not. So timegm(Linux) does not either.
Strange.

I tried to find source code of timegm. This one would match my
expectations by function __mktime_internal():
  
http://glibc.sourcearchive.com/documentation/2.9-9ubuntu2/mktime_8c-source.html

But that one is darn complicated. It is described as a function inversion
by try-and-error. If i only could spot that function in the code salad :(

I see this remark:
/* Assume that leap seconds are possible, unless told otherwise.
   If the host has a `zic' command with a `-L leapsecondfilename' option,
   then it supports leap seconds; otherwise it probably doesn't.  */
My Linux got no "zic".
So this could explain why your algorithm matches my Linux.

But what about machines which do know about leap seconds ?
According to wikipedia we had dozens of them since 1970.

-------------------------------------------------------------------------

The putenv() way looks less tricky, but it also looks like a
performance hog. timegm() gets called by libisofs for each single file
that gets read or written.
An experiment indicates that it is up to 20 times slower than
your straightforward implementation. 30 seconds for a million
calls on a 3000 MHz 64 bit system.

Again it turned out that no leap seconds are accounterd for on
my Linux.

-------------------------------------------------------------------------

So now for gnulib.
GPLv3 and FSF copyright is no problem for GNU xorriso but i would
not import them into libburnia which strives to become LGPL some
day.
Reading http://wiki.opencsw.org/adding-gnulib is not very encouraging
for me. My autotools knowledge is strictly heuristic.

------------------------------------------------------------------

Result:

Despite the speed penalty, the winner is currently something like

  #ifdef __sun
  #define Libisofs_use_putenV yes
  #endif

  time_t soft_timegm(struct tm *tm)
  {

  #ifdef Libisofs_use_putenV

      ... implementation with putenv() rather than setenv(), unsetenv() ...

  #else /* Libisofs_use_putenV */

      time_t ret;
      char *tz;

      tz = getenv("TZ");
      setenv("TZ", "", 1);
      tzset();
      ret = mktime(tm);
      if (tz)
          setenv("TZ", tz, 1);
      else
          unsetenv("TZ");
      tzset();
      return ret;
  }

  #endif /* ! Libisofs_use_putenV */

I will later try to move the timezone setting out of the loops which iterate
over the file tree. A naked mktime() is not significantly slower than
your implementation of timegm().

To my luck putenv(3) is known on my Linux. 
Oracle has replaced the web man pages by a documentation index.
I needed 5 minutes to find putenv(3C). They do not charge money ... yet. 

Scary semantics, on Solaris and Linux alike.
If i get it right then i am supposed to subtract 3 from the pointer
returned by getenv() and submit the result as pointer to putenv().
Eww.
But submitting a static variable would interfere with the promise
of putenv() to keep the variable string open to side effects.

Actually the use of setenv() is neither portable nor harmless.
It does spoil eventual putenv() tricks which might be attempted
by the application above libisofs.

If there only were no leap seconds !


I now started experiments with the putenv solution on Linux.


Have a nice day :)

Thomas