Status of config file parser

[Russ Allbery]

Brian Kantor <brian at UCSD.EDU> writes:

> Since the parser doesn't use the stdio library, I am led to wonder how
> it will cooperate with the stdio library if it is indeed in use.

Well, at present, the only interface is to pass it a file name and get
back a parse tree, with the file opened, read, and closed internally
before the function returns.  So there isn't much cooperation necessary.

When there is an API for writing back a modified configuration file, I may
actually use stdio for that; I'm not sure yet.  The only reason to not use
stdio for parsing a configuration file is because of the special needs of
innd, nnrpd, and the other portions of the news subsystem that routinely
have to open a huge number of files.

But the library just uses open/read/close directly, so even in the
presence of an additional interface that takes an open file, it should
still work reasonably well with stdio.  I guess what may not work is
passing in a FILE * and still having all the buffering and whatnot handled
consistently under the hood, but I'm not sure how important it is to be
able to do that.

> stdio is very convenient, useful, and not all the inefficient, so many
> programs still use it, and I would not like to see the parser be
> incompatable with it if the parser is also to be a separate standalone
> package.

*nod*  Agreed.  The problem with stdio, however, is that many systems
chose to use an unsigned char to hold the file descriptor number in the
FILE struct, which means that in order to use stdio within something like
INN, one has to reserve low-numbered file descriptors and play other
games, and given that config files can include other config files, the
number of file descriptors one has to reserve is potentially unbounded.
It looked like the best way to avoid all of that and let innd still read
configuration files on the fly was to bypass stdio.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>