On Oct 21, 2016, at 6:21 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/21/2016 06:00 PM, Guy Harris wrote:
Should there be a comment
Yes, it appears so. How about the attached?
It looks good, although the documentation of the purpose of that code appears to be split between the comment in localtime.c: /* Convert from the underlying system's time_t to the ersatz time_tz, which is called 'time_t' in this file. Typically, this merely converts the time's integer width. On some platforms, the system time is local time not UT, or uses some epoch other than the POSIX epoch. Although this code appears to define a function named 'time' that returns time_t, the macros in private.h cause this code to actually define a function named 'tz_time' that returns tz_time_t. The call to sys_time invokes the underlying system's 'time' function. */ and the comment in private.h: /* ** Compile with -Dtime_tz=T to build the tz package with a private ** time_t type equivalent to T rather than the system-supplied time_t. ** This debugging feature can test unusual design decisions ** (e.g., time_t wider than 'long', or unsigned time_t) even on ** typical platforms. */ So: 1) Is this only a debugging feature? 2) Is it intended only to be used on platforms that provide a native time() call and only to map that result to a seconds-since-the-Un*x-Epoch value of a specified integral type (which might not be the OS's time_t type, so it could be used even on UN*X), rather than to be used as a wrapper around whatever the OS's "native" "what's the current date and time of day" API is? If 1) isn't (is no longer?) true, the comment in private.h should probably be updated. If 2)