[ntp:hackers] NTP Development Snapshot 4.3.45 Released
Hal Murray
hmurray at megapathdsl.net
Thu Jun 25 01:50:11 UTC 2015
Make check didn't work for me.
I have some local additions to the config file so every time that area
changes I have to rebuild ntp_keyword.h and ntp_parser.{c,h}
I tracked my problem down to an #ifdef LEAP_SMEAR in ntpd/keyword-gen.c
I don't claim to understand this area. It looks like there are two parallel
definitions of the token encodings. There is the one in ntpd/keyword-gen.c
that is only used by ntpd/ntp_scanner.c The same tokens with their own
definitions are in ntpd/ntp_parser.{c,h} ntp_parser.h is also included by
ntp_scanner.c
I assume the handoff between ntp_scanner and ntp_parser expects those tokens
to have the same values.
ntpd/ntp_parser.c: T_Leapsmearinterval = 331,
ntpd/ntp_parser.c:#define T_Leapsmearinterval 331
ntpd/ntp_parser.h: T_Leapsmearinterval = 331,
ntpd/ntp_parser.h:#define T_Leapsmearinterval 331
ntpd/ntp_keyword.h: /* 73 331 T_Leapsmearinterval */ NULL,
The "T_Leapsmearinterval = 331" are both in an enum.
------
It looks to me like you built ntp_keyword.h with LEAP_SMEAR defined while I
rebuilt it without LEAP_SMEAR so all my tokens past 331 were off by one.
I don't know how to fix this cleanly. If the #ifdef stays in keyword-gen,
then we have to add something parallel to ntp_parser and that adds bison to
the list of required tools. If we take the #ifdef out, then we have to add
error handlers to the runtime.
Either way, we have to add the equivalent logic when building complete.conf
(or just not test optional cases)
------
In the short term, it might be a good idea to add a sanity check trap to
compare the lengths of the two tables. I'm not sure where that should go.
--
These are my opinions. I hate spam.
More information about the hackers
mailing list