[ntp:hackers] NTP Development Snapshot 4.3.45 Released
Harlan Stenn
stenn at ntp.org
Thu Jun 25 03:16:39 UTC 2015
Hal Murray writes:
> Make check didn't work for me.
In what way?
> 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.
I'm thinking about how to fix this too.
I'm open to ideas.
I'd rather not require bison or yacc to build NTP either.
H
More information about the hackers
mailing list