[ntp:hackers] Cool new stuff

Danny Mayer mayer at ntp.isc.org
Tue Jul 25 04:38:09 UTC 2006

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
> expected.

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 when
> 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
> happening.

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 startup.
> I think we could have a flag that turns on silent mode or we should specify
> 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.
> Regards,
> Sachin.

More information about the hackers mailing list