- tz - lists.iana.org

[PROPOSED 0/6] unlikely integer overflow fixes
by Paul Eggert Nov. 20, 2022

Nov. 20, 2022

This patch set fixes some unlikely integer overflow bugs. These patches are relevant only for unusual situations, e.g., objects so large that their sizes exceed PTRDIFF_MAX bytes; or for unusual architectures, e.g., architectures where INT_MAX == UINT_MAX. In most cases I do not know of any practical way to exploit the bug, even if POSIX says the bug is possible. Paul Eggert (6): Don’t assume INT_MAX < UINT_FAST64_MAX Fix size_t overflow check if SIZE_MAX == INT_MAX date: integer overflow fixes Improve integer overflow checking in zdump Fix theoretical integer overflow in zic.c Fix another theoretical zic.c overflow NEWS | 3 ++ date.c | 32 +++++++------------ private.h | 4 +++ zdump.c | 64 +++++++++++++++++++++----------------- zic.c | 92 +++++++++++++++++++++++++++++++++++-------------------- 5 files changed, 113 insertions(+), 82 deletions(-) -- 2.38.1

1 6

[PATCH 1/5] Simplify inputline return value
by Paul Eggert Nov. 20, 2022

Nov. 20, 2022

* zic.c (inputline): Return bool, not ptrdiff_t. All callers changed. --- zic.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/zic.c b/zic.c index 548c1c5..0671889 100644 --- a/zic.c +++ b/zic.c @@ -1575,10 +1575,9 @@ associate(void) /* Read a text line from FP into BUF, which is of size BUFSIZE. Terminate it with a NUL byte instead of a newline. - Return the line's length, not counting the NUL byte. - On EOF, return a negative number. + Return true if successful, false if EOF. On error, report the error and exit. */ -static ptrdiff_t +static bool inputline(FILE *fp, char *buf, ptrdiff_t bufsize) { ptrdiff_t linelen = 0, ch; @@ -1589,7 +1588,7 @@ inputline(FILE *fp, char *buf, ptrdiff_t bufsize) exit(EXIT_FAILURE); } if (linelen == 0) - return -1; + return false; error(_("unterminated line")); exit(EXIT_FAILURE); } @@ -1604,7 +1603,7 @@ inputline(FILE *fp, char *buf, ptrdiff_t bufsize) } } buf[linelen] = '\0'; - return linelen; + return true; } static void @@ -1626,13 +1625,11 @@ infile(int fnum, char const *name) } wantcont = false; for (num = 1; ; ++num) { - ptrdiff_t linelen; char buf[_POSIX2_LINE_MAX]; int nfields; char *fields[MAX_FIELDS]; eat(fnum, num); - linelen = inputline(fp, buf, sizeof buf); - if (linelen < 0) + if (!inputline(fp, buf, sizeof buf)) break; nfields = getfields(buf, fields, sizeof fields / sizeof *fields); -- 2.38.1

1 4

[PROPOSED 0/4] Port to C89, and deprecate C89
by Paul Eggert Nov. 19, 2022

Nov. 19, 2022

While looking into fixing some bugs in tzcode, I noticed some places where existing code wouldn’t work with ancient C89 compilers. I fixed the problems I found in this patch series. Quite possibly other problems remain, problems that I didn’t notice. As nobody has reported C89-related problems for ages, it appears that these old compilers are no longer being used to compile tzcode. So I propose that we remove C89 support, to avoid future maintenance burdens such as the one I recently went through. As part of the transition away from C89 support, the last patch in this series announces that C89 will be removed in some future release. We can keep C89 support for at least one release longer. Paul Eggert (4): Port to C89 gcc -pedantic Port UINT_FAST64_MAX back to C89 Port int_fast64_t to C89 64-bit long * NEWS: Deprecate C89. NEWS | 7 +++++++ private.h | 47 +++++++++++++++++++++++------------------------ 2 files changed, 30 insertions(+), 24 deletions(-) -- 2.38.1

1 4

Re: [tz] Country name change from Turkey to Turkiye
by Brian Inglis Nov. 19, 2022

Nov. 19, 2022

On 2022-11-17 23:09, Bin Li via tz wrote: > Do you have any plans to change Turkey's name? Because it's the official name now. > https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-… <https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-…> One of the stupider ISO decisions, as English supports no accents, except in loanwords, and they are just ignored, except possibly in academic publishing. I think it is time native English language speakers push back against and ignore decisions made by international committees of non-native English language speakers, to try and change what native English language speakers use to what the foreign language uses in Latin alphabet transliterations, just as the other 100+ countries who have no "official" transliteration do. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

3 2

Country name change from Turkey to Turkiye
by Bin Li Nov. 18, 2022

Nov. 18, 2022

Dear, Do you have any plans to change Turkey's name? Because it's the official name now. https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-…

6 8

New York Times: Time is Running Out for the Leap Second
by Jonathan Leffler Nov. 15, 2022

Nov. 15, 2022

https://www.nytimes.com/2022/11/14/science/time-leap-second.html -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick Nov. 14, 2022

Nov. 14, 2022

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

[PATCH] use official source for 1993 end of time shift
by Alois Treindl Nov. 12, 2022

Nov. 12, 2022

--- southamerica | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/southamerica b/southamerica index 13cc65e..8eb5e25 100644 --- a/southamerica +++ b/southamerica @@ -1417,10 +1417,13 @@ Zone Antarctica/Palmer 0 - -00 1965 # Milne gives 4:56:16.4 for Bogotá time in 1899. He writes, # "A variation of fifteen minutes in the public clocks of Bogota is not rare." +# Alois Treindl quoted DECRETO 267 DE 1993 +# https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 +# Artículo 2° El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - -Rule CO 1993 only - Apr 4 0:00 0 - +Rule CO 1993 only - Feb 7 0:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] #STDOFF -4:56:16.4 Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 -- 1.8.3.1

2 1

Re: [tz] Minor (unimportant really) technical UB bug in strftime() ?
by Brian Inglis Nov. 12, 2022

Nov. 12, 2022

On 2022-11-11 13:53, Paul Eggert via tz wrote: > On 2022-11-10 16:11, Tom Lane wrote: > >> simple modifications of the >> strftime() case can provide pretty good examples. > I'm not sure I'm following this argument, but if I understand it correctly I > disagree. I very much much want implementations to reject attempts to use > uninitialized data, and I don't want the C standard to prohibit such > implementations. Use of uninitialized data is a serious problem in real > applications - several CVEs have arisen from it - and the C standard shouldn't > require implementations to sweep it under the rug. > This call is obviously buggy since it is passing an uninitialized struct tm to > strftime. However, the C standard says the patched strftime's memcpy initializes > strftime's local variable tm, and therefore mktime's use of tm's contents is > defined and the implementation allow the program's use of uninitialized data. > > Whatever the reason for this peculiarity of the C standard (and nobody seems to > remember why it's there), it's counterproductive. In general C programs > shouldn't use uninitialized data. If they do, it's useful to have a debugging > implementation that reports any such use the instant that it happens as this > will help catch real bugs. And since common debugging implementations like > valgrind and UBSan are not following the C standard here, this suggests that the > C standard is mistaken, not the implementations. >> That leads either to strftime() knowing >> much more about mktime()'s innards than it ought to > It's not a problem for strftime, since strftime's has to know what's needed in > the struct tm; this follows from strftime's API. It may not know everything about the object, as there may be implementatiion extensions to deal with e.g. localization issues, and can never know everything about another function implementation, which could be changed at any time. > It might be a problem for other scenarios, such as the one you vaguely suggested > though I don't know the details. However, even assuming these other scenarios > exist, they don't justify this peculiarity of the C standard. The standard > should not say that the ordinary meaning of "don't use uninitialized variables" > is wrong and that there's some trickier interpretation that hardly any > programmer knows and that was wrong even in C17 and so needed rewording (and > perhaps still needs rewording) and that nevertheless must be supported - even > though important debugging implementations disagree. I think the principle is just to program carefully and generically around possible issues, when dealing with an opaque object you do not define and control, to avoid creating issues with private fields or functions which may be part of the implementation, but not in whatever documented interface you are programming to. Not all the world is...C, POSIX, or Linux, compliant. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

Minor (unimportant really) technical UB bug in strftime() ?
by Robert Elz Nov. 11, 2022

Nov. 11, 2022

The code for the %s strftime conversion starts as: (this taken from tzcode2022f strftime.c - but I suspect that many versions are the same) case 's': { struct tm tm; char buf[INT_STRLEN_MAXIMUM( time_t) + 1]; time_t mkt; tm = *t; mkt = mktime(&tm); The "tm = *t;" line is the problem. It (or more correctly, something to replace that) is needed, as *t is const, strftime() is not permitted to modify it, yet the struct tm * passed to mktime() is not const, as mktime is sometimes required to modify that struct before returning. However, mktime() refers only to the fields tm_year tm_mon tm_mday tm_hour tm_min tm_sec and tm_isdst of the struct passed to it. The %s conversion is defined as producing (in a decimal string format) the result of mktime() applied to the struct tm passed to strftime. Hence an application which intends to use strftime(..., "%s", ...) need only initialise those 7 fields, the other 2 (currently) standard fields (tm_yday and tm_wday) are explicitly ignored by mktime() on input, so there is no need to assign those values, and any other fields that might exist in a particular implementation are out of scope for a portable (conforming) application to touch, so cannot be initialised. Since referring to an uninitialised variable is, I believe, technically undefined behaviour, doing a struct copy (copying all fields) can have that effect. (An application could memset() the entire struct before providing the values it must add, but is not required to do that). It seems likely that the simple fix is to replace the struct assignment with 7 individual assignment statements tm.tm_year = t->tm_year; tm.tm_mon = t->tm_mon; /* ... */ On the other hand, hardware that balks at simply loading or copying, uninitialised values, without using them for any purpose is not exactly common (and half the world's code would probably break if an implementation that worked in such a manner was ever created) so I'd call this one of the less significant issues to worry about fixing. kre

10 26