On 05/24/2017 08:14 AM, Kees Dekker wrote:
I agree with you regarding slashes, because (most) Windows API functions allow to use UNIX-style slashes. But support for drive letters is a must have on Windows, as the root (in UNIX terms) of a process is relative to a drive. If a process was started from drive D:, Then '/' points to D:, but if the zonefiles exist on drive C:, they can't be opened.
I don't see why they can't be opened. If the value of the TZDIR macro is "C:/zoneinfo", then calling tzalloc("America/Los_Angeles") opens the file "C:/zoneinfo/America/Los_Angeles" even when the process's working directory is D:/foobar. Although it's true that tzalloc("C:/zoneinfo/America/Los_Angeles") won't access the file in question, we shouldn't need to worry about supporting this unusual use case on MS-Windows. Even on POSIX platforms, using absolute filenames for time zones is a questionable practice and some systems disable it for security reasons. I think Robert covered the other points of your email. (In particular, look for tzalloc, localtime_rz, and mktime_z.)
Also, that's why we have improved mkime (with the time_succesive() code), as the current approach is pretty inefficient. If this change can be separated out and made portable and reliable in the presence of integer overflow and unsigned time_t and so forth, it should be OK. As I recall the proposed change is a long way from that, though. From my point of view the simplest thing to do would be change the code to use GNU mktime, as a build-time option (default off) for people who want speed and don't mind the GPL.