Fwd: Bulletin C number 58
On Sat Jul 27 14:21:34 UTC 2019, Paul Eggert <eggert at cs.ucla.edu> wrote:
Thanks, I installed that into the development version on GitHub.
I see that the updated file has a space at the end of the '#@ 3802291200' line that encodes the expiration (2020-06-28 00:00:00 UTC). I assume this was inadvertent. It doesn't break tzcode (which ignores that line), but the format of the line is not documented anywhere that I can see. I dropped Judah Levine a line about this.
Back in the dark ages, when I first started writing C code, it was said that the ultimate documentations was the code. In the NTP daemon, there is a subroutine leapsec_load() in which is the following: while (get_line(func, farg, linebuf, sizeof(linebuf))) { cp = linebuf; if (*cp == '#') { cp++; if (*cp == '@') { cp = skipws(cp+1); pt->head.expire = strtouv64(cp, &ep, 10); ... strtouv64() is an NTP native subroutine (found in libntp/vint64ops.c) which reads numeric data in a specified base (in this case 10). It skips "whitespace" (so the call to skipws() is superfluous), and then converts the digits, one at a time, to numeric in that base. It quits conversion when whatever it's pointing at isn't a digit in the selected base and returns the number and "ep", a pointer to where it stopped parsing. This allows for comments and/or additional data. So, a space instead of a line terminator or say, a comment such as "\t# 28 Jun 2020", after the expiration NTP timestamp is an acceptable field termination. Anyone who cares to can reference the "standard" implementation of the NTP code found at: <http://www.ntp.org/downloads.html> The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server...
On 7/27/19 3:15 PM, Chris Woodbury wrote:
Back in the dark ages, when I first started writing C code, it was said that the ultimate documentations was the code. In the NTP daemon
Sure, but the NTP daemon is not the only consumer of that data. One other consumer is Git, which complained to me about that trailing space, which is how I noticed it. A minor annoyance, but other consumers might fail harder. It's only a minor problem, and perhaps it would save us all time if we just stripped that trailing white space ourselves rather than blindly copying the NIST file.
On Jul 27, 2019, at 3:24 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
One other consumer is Git, which complained to me about that trailing space, which is how I noticed it. A minor annoyance, but other consumers might fail harder.
I don't think Git itself cares about trailing spaces, unless it supports a configuration option to make it do so. There might be commit hooks that are checking for that (Wireshark has some).
On 7/27/19 6:15 PM, Guy Harris wrote:
I don't think Git itself cares about trailing spaces, unless it supports a configuration option to make it do so.
There might be commit hooks that are checking for that (Wireshark has some).
Right on both counts. The sample Git hooks in .git/hooks/pre-commit.sample check for trailing white space, because it makes the output of 'git diff' fragile in email etc., and I'm following this lead in my own Git repository. tzdb 'make check_white_space' does something similar, for similar reasons. It currently has an exception for leap-seconds.list, which I'd rather remove.
Chris Woodbury via tz said:
Back in the dark ages, when I first started writing C code, it was said that the ultimate documentations was the code.
"If the code and the comments disagree, they're probably both wrong." -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Dear Colleagues, I have removed the trailing spaces that you noticed and the new files are now posted at both ftp locations. With all due respect and with no offense intended, I suggest that software that is sensitive to trailing whitespace should be re-considered. The comment lines are intended to be helpful for any poor soul who is not familiar with the various time formats and the definition of leap seconds. I consider that stuff to be helpful explanations and not data. The point of making them comments is that they could be easily ignored by the usual software that parses scripts and by users who understand all of the strange and wondrous details of UTC. I designed the two "special" comment lines so that they could be found by reading the first two characters on every line in the file without parsing every line. Also, they would not have to be at any special line number in the file. I did not invent this idea -- UNIX scripts use the same method to identify the shell. For example, a script that did not care about the checksum could ignore that value without any special processing. I invented the file format in the dark ages based on what I thought would be useful at the time. I will *consider* improvements or changes with the understanding that the file is used on many different and incompatible operating systems. Any "improvement" that breaks this requirement is unlikely to be useful. Best wishes, Judah Levine On 7/29/2019 7:01 AM, Clive D.W. Feather wrote:
Chris Woodbury via tz said:
Back in the dark ages, when I first started writing C code, it was said that the ultimate documentations was the code. "If the code and the comments disagree, they're probably both wrong."
-- Judah Levine Time and Frequency Division NIST Boulder
On 2019-07-29 08:03, Judah Levine via tz wrote:
I have removed the trailing spaces that you noticed and the new files are now posted at both ftp locations. With all due respect and with no offense intended, I suggest that software that is sensitive to trailing whitespace should be re-considered. The comment lines are intended to be helpful for any poor soul who is not familiar with the various time formats and the definition of leap seconds. I consider that stuff to be helpful explanations and not data. The point of making them comments is that they could be easily ignored by the usual software that parses scripts and by users who understand all of the strange and wondrous details of UTC. I designed the two "special" comment lines so that they could be found by reading the first two characters on every line in the file without parsing every line. Also, they would not have to be at any special line number in the file. I did not invent this idea -- UNIX scripts use the same method to identify the shell. For example, a script that did not care about the checksum could ignore that value without any special processing. I invented the file format in the dark ages based on what I thought would be useful at the time. I will *consider* improvements or changes with the understanding that the file is used on many different and incompatible operating systems. Any "improvement" that breaks this requirement is unlikely to be useful.
"Be liberal in what you accept, and conservative in what you send" -- RFC 1122, Robustness Principle: Postel's Law, Jon Postel Git check-in hooks for such issues should either be warnings, or configured to ignore all upstream sources: you should always be able to check in upstream sources as is. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
participants (6)
-
Brian Inglis -
Chris Woodbury -
Clive D.W. Feather -
Guy Harris -
Judah Levine -
Paul Eggert