On 10/28/18 9:23 PM, Paul Eggert wrote:
'zdump New_York' is treated differently from 'zdump ./New_York'. It might make sense for the code to try harder to treat only ".." components differently.
I installed the attached first patch to try to do that. The second attached patch silences a warning when running "make CFLAGS='$(GCC_DEBUG_FLAGS)' GCC_INSTRUMENT=" on my platform (I updated GCC recently).
Just noticed something that may explain my previous findings.
From the tz variable man page:
From: tz <tz-bounces@iana.org> on behalf of Paul Eggert <eggert@cs.ucla.edu> Sent: Monday, October 29, 2018 8:47 AM To: Arthur David Olson Cc: Time Zone Mailing List Subject: Re: [tz] zdump bug? On 10/28/18 9:23 PM, Paul Eggert wrote:
'zdump New_York' is treated differently from 'zdump ./New_York'. It might make sense for the code to try harder to treat only ".." components differently.
I installed the attached first patch to try to do that. The second attached patch silences a warning when running "make CFLAGS='$(GCC_DEBUG_FLAGS)' GCC_INSTRUMENT=" on my platform (I updated GCC recently).
Just noticed something that may explain my previous findings.
From the tz variable man page:
http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html "If characters begins with a slash, it is an absolute file name; otherwise the library looks for the file /usr/share/zoneinfo/characters." Thus starting with a period is what throws it off? -Matt ________________________________ From: tz <tz-bounces@iana.org> on behalf of Paul Eggert <eggert@cs.ucla.edu> Sent: Monday, October 29, 2018 8:47 AM To: Arthur David Olson Cc: Time Zone Mailing List Subject: Re: [tz] zdump bug? On 10/28/18 9:23 PM, Paul Eggert wrote:
'zdump New_York' is treated differently from 'zdump ./New_York'. It might make sense for the code to try harder to treat only ".." components differently.
I installed the attached first patch to try to do that. The second attached patch silences a warning when running "make CFLAGS='$(GCC_DEBUG_FLAGS)' GCC_INSTRUMENT=" on my platform (I updated GCC recently).
On 11/1/18 10:42 AM, Matt Johnson wrote:
"If characters begins with a slash, it is an absolute file name; otherwise the library looks for the file /usr/share/zoneinfo/characters."
Thus starting with a period is what throws it off?
Depends on what you mean by "throws it off". All the "." does in 2018g is cause 'access' to be called in addition to 'open'; this rarely matters in practice.
Re the proposed patch to try to avoid access calls on arguments that contain just a single dot (changing the code to look for ".."): There are no filenames with any dots in the zoneinfo tree produced from an unmodified tz distribution. So whether or not access is called, there will be one system call for a dot-containing argument; either access or open will fail and no further calls will be made. Avoiding the access call doesn't save a system call. (Looking for ".." rather than "." will save a call on customized systems that put dot-containing names in the zoneinfo tree.) @dashdashado On Mon, Oct 29, 2018, 11:47 AM Paul Eggert <eggert@cs.ucla.edu wrote:
On 10/28/18 9:23 PM, Paul Eggert wrote:
'zdump New_York' is treated differently from 'zdump ./New_York'. It might make sense for the code to try harder to treat only ".." components differently.
I installed the attached first patch to try to do that. The second attached patch silences a warning when running "make CFLAGS='$(GCC_DEBUG_FLAGS)' GCC_INSTRUMENT=" on my platform (I updated GCC recently).
On 11/8/18 8:41 AM, Arthur David Olson wrote:
There are no filenames with any dots in the zoneinfo tree produced from an unmodified tz distribution. So whether or not access is called, there will be one system call for a dot-containing argument; either access or open will fail and no further calls will be made.
There are two system calls for TZ values like "./America/New_York" and "America/././New_York". Although we could change the code to reject these TZ values, historically they have been valid and they're supported on many platforms. And alhough these TZ values are rarely used, they were (wrongly) used in the thread <https://mm.icann.org/pipermail/tz/2018-October/027126.html> that prompted the change <https://mm.icann.org/pipermail/tz/2018-October/027135.html>. You could easily talk me into reverting the change, as it's more of a "let's make strace output look nice even with weird TZ settings" change than a change that actually fixes a bug or significantly improves performance.
participants (3)
-
Arthur David Olson -
Matt Johnson -
Paul Eggert