[ntp:hackers] Cool new stuff
David L. Mills
mills at udel.edu
Tue Jul 25 20:05:38 UTC 2006
Yes, there is a BNF grammar for the existing configuration file; that's
how it now works. However, some features like the simulator scripts are
just too awkward with the existing regular expression style. Our intent
is to, at least for the predicable future, to have one grammar for the
existing style and another grammar for the flavor of the month, however
that might develop. Selection would be by command line option with
default the existing style.
Context-dependent reserved words seems like a very bad idea in the first
place; but heck, I cut my teeth on language design and compiler
construction thirty years ago in my dissertation. The filegen command is
not the only place where a reserved word conflict will exist. The
driftfile, keys, crypto and include commands among others will have the
Sachin might be able to deal with this problem, but it will be ugly.
Danny Mayer wrote:
> Sachin Kamboj wrote:
>> On 7/22/06, Danny Mayer <mayer at ntp.isc.org> wrote:
>>> I'm not sure I understand why they need to be reserved words. The syntax
>>> should be clearly established to differentiate between a name and a
>>> value on a line. If you can't then the syntax should be revised.
>> The fact that keywords are reserved has nothing to do with the syntax
>> or the parser. It has to do with the scanner (lexical analyzer). To
>> keep things simple, the parser asks the scanner for the next token.
>> The scanner on seeing the keyword, returns the token for the keyword
>> instead of returning a string, which is what the parser expects. The
>> scanner does not know (and should not know) that a string is
> Keywords in languages like C are done for a special reason, the code
> could otherwise get misinterpreted in unintended ways. There are very
> few of these. I chose to reserve stdout as a special keyword on the ntpd
> command line as there is no other way to specify this, but anything else
> is a filename to the -l option. The argument to -l is STILL a filename,
> it just has a special meaning.
>> Whereas, it is certainly possible to have the parser guide the
>> scanner, it
>> introduces complexity and bugs for absolutely no gain in value (either to
>> the user or the developer). For this reason, most modern languages
>> (including C) make keywords reserved.
> No, that's almost certainly no true. Certain words are reserved to
> eliminate ambiguities and for no other reason. Most modern compilers are
> very complex and try and deal with every type of input imaginable. We
> are dealing with real-life configuration files and there are always
> errors in them. Don't expect perfection, you won't get it. In testing I
> sometimes add deliberate errors to see how it gets handled.
>> I can understand the concern that this breaks the existing usage. I
>> am considering allowing the use of C-style strings to overcome this
>> resistance - even though I am not convinced that doing so is a good
>> idea. See one of my previous emails for my reasons. I will allow
>> Prof. Mills to have the final say in the way things will work.
> My understanding is that the new configuration file breaks existing
> usage anyway so why worry about that part?
> Do you have a BNF grammar for the configuration file?
>> However, I believe it is brain dead to continue to run and do nothing
>> ntpd can't find the configuration file. It should display an error at the
>> least and hopefully exit gracefully. Also, all parse errors should be
>> displayed by default. I have been working on NTP for a year now and this
>> threw me off. Fortunately, I could read the code and figure out what was
> Yes, preferably with line numbers and some reference to the problem.
>> I understand that daemons should go about their work as silently as
>> possible, especially if they are called through init/rc scripts at
>> I think we could have a flag that turns on silent mode or we should
>> that all errors will be logged into the system logs.
> I always log the interfaces that it uses to ensure that the sysadmin
> knows where it's listening.
>> I'd be happy to receive your and other fellow hacker's comments on
>> this and
>> any other aspect of the configuration process.
More information about the hackers