Marek Behun wrote:

I have written a small POSIX timestamp compatibility library for glibc/linux systems which use right timestamp on system clock (and also a 'right/' timezone).

By executing a program with LD_PRELOAD=/path/to/time2posix.so

This is interesting and valid, but scarily fragile. It's something of a problem that time_t in general has these two interpretations (the POSIX interpretation and the one implied by the `right' tz files). At present the problem is minimised firstly by the inherent segregation between `posix' hosts and `right' hosts, and secondly by the sheer rarity of the latter. Your library does away with the per-host segregation, so that now different time_t slots on a single host have different interpretations. This *can* be done correctly, but having your modified time() et al masquerade as the ordinary libc functions makes it as difficult as possible. As a single program can be run against either version of the functions, there's no explicit indicator of which flavour of time_t is being used, and it's not immediately obvious when there's a mismatch, you're bound to get them mixed up sometimes. Anyone who uses the preload has to be aware of this, and to track very carefully where time_t is used (in data files, where it's not necessarily documented) and which flavour of it is used in each place.

when using for example ntpdate to synchronize from such a server, ntpdate doesn't have to be patched to synchronize to right timestamp (instead of posix).

Interesting, that's pretty much the reverse of the use cases I first imagined. (I was thinking of user-oriented programs getting the preload, where they embed too much knowledge of the POSIX version of time_t to function correctly on a `right' system.) Whichever programs it's used on, minimising the number of them helps in keeping the two versions of time_t separate. The worst possible arrangement would be to apply the preload to the majority of programs.

I would like to know if I should continue developing this library

I can't give a good answer about the prevalence of the `right' system. I think your library is a useful aid for people who do run such systems, or who would like to but are currently put off by the incompatibilities it would suffer. I see that you only read the leap second table once, at startup. This will go wrong for long-running programs such as ntpd. You should periodically check for newly-announced leap seconds by rereading the LEAP_TZFILE. The trigger condition for this should be something like the time_t that you're converting being over a month later than the time was when you last read the file. -zefram