On Tue, Nov 01, 2022 at 05:20:17AM +0700, Robert Elz wrote: > [a small book]
You can rehash the same points over and over again, and continue to introduce irrelevant distractions, and continue to assert without evidence that correct behavior is impossible, but the various facts remain: (a) It follows from the observations so far that if I set ->tm_gmtoff to 101 and ->tm_zone to "abracadabra" (as well as populating the rest of the structure), and ask strftime to print those fields, it will not print them but print something else. I continue to fail to see how this is anything other than a bug. Similarly, if I ask it to print %s, it will bring the wrong time_t value. I continue to fail to see how *this* is anything other than a bug. (b) Our implementation contains the timezone info in struct tm. This does not make our implementation noncompliant; the current posted text says "The <time.h> header shall declare the tm structure, which shall include at least the following members:", not "exactly the following members". It follows (I can find no text to contradict this) that consing up your own struct tm to call strftime without bzeroing it first risks producing undefined behavior and is therefore incorrect. (c) Consequently it's easy to construct a compliant implementation that contains tm_gmtoff and tm_zone in struct tm and where strftime behaves correctly with respect to these values for %z, %Z, and %s. (Whether our implementation can be corrected without a compat mess is less clear.) (d) It is, in general, quite easy to write standards language that acceps both full correct and less than ideal implementations for cases where the incorrect implementations cannot be fixed. In fact, the current posted text says: : If a struct tm broken-down time structure is created or modified by : gmtime() or gmtime_r(), it is unspecified whether the result of the : %Z and %z conversion specifiers shall refer to UTC or the current : local timezone, when strftime() is called with such a broken-down : time structure. That is more specific than I had suggested, but clearly completely suitable. (And given this text, I completely fail to understand why they are proposing to change things.) (e) Standardization that precludes a correct implementation, or that mandates an incorrect implementation, remains wrong and inappropriate. Meanwhile we've clearly reached the point where you're wilfully misinterpreting what I'm writing in order to dismiss it, not to mention introducing specious analogies and committing a couple other rhetorical fouls. So I have a feeling that nothing productive is likely to happen going forward. -- David A. Holland dholl...@netbsd.org
