[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schmitt
Subject: [Bug-xorriso] Re: Portability issues of xorriso on Solaris 9
Date: Tue, 18 Jan 2011 12:13:42 +0100


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
- By using gmtime() to produce the test struct tm, my million tests
  are somewhat flawed. What cannot come out of gmtime() cannot get

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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]