[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