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

[Thomas Schmitt]

Hi,

What is the copyright situation of your proposed timegm() implementation
in 0003-Use-timegm-substitute-which-does-not-use-setenv.patch ?

If it is by you: are you willing to donate the copyright to libisofs,
or to license it under "BSD revised" (it's yours but everybody may use
it without any restriction), or under LGPLv2+.


The quote about POSIX not allowing leap seconds made me think again
about the putenv approach. It is slow and i got a bad feeling with
the following gesture:
    tz = getenv("TZ");
    ...
    if (tz != NULL)
        putenv(tz - 3);
which is nevertheless the only one that complies to the putenv semantics.

So i now go for this:

    Make local copy of input struct tm.
    Call your implementation of timegm().
    With the resulting time_t call gmtime() (which may alter input tm).
    Compare the resulting struct tm with the copied input struct tm.
    In case of mismatch call the function that uses putenv()+mktime()
    (take care to use the copied input tm, not the original tm pointer).

This will avoid two potential pitfalls:
- Machines with leap second processing will be served slowly but
  correctly.
- By using gmtime() to produce the test struct tm, my million tests
  are somewhat flawed. What cannot come out of gmtime() cannot get
  tested.


It still stays a mine field, with (tz-3) and gmtime() possibly re-using
the input tm if it stems from gmtime() or alike.
Non-compliant getenv() implementations on leap-second machines might cause
memory faults.
Maybe i should go for the try-and-error approach of gnulib rather than
using putenv().


Have a nice day :)

Thomas