dfree confpars.c(648): free on null pointer.

[John Hascall]

> On Fri, Feb 22, 2008 at 09:23:37AM -0600, John Hascall wrote:
> > So, is it a feature or a bug that everything has to use the
> > same name for options?

> Hm.  I'm not sure we ever thought of it as an option even.

> Storytime...
> In 3.1.0, we took on support for the VIVSO options, ...

> I guess this is just a long winded way of explaining that we never
> knew multiple option name->code definitions ever worked, or at least
> were never intended to, and are equally surprised that anyone actually
> tried it that way.

Well, I'd never hand-write a dhcpd.conf that way, but
as I mentioned, ours is auto-built from several data
sources (under the control of multiple people, of course).
It looks like I'll just have to add yet another data
massaging bit which is fine.

> I don't know if the code should or shouldn't permit this.  For the
> server it doesn't matter so much, but it's...weird...for the client,
> which has to dump options contents to dhclient.leases and format stuff
> into environment variables for dhclient-script.  I don't really want
> to make up my mind based off of what I think makes the prettiest api.

My initial thought was that the dhclient.leases issue means it should be
disallowed, but then it occurred to me that just maybe the option code
should be stored numerically in dhclient.leases -- if you store it by
name then you have a possibly unexpected tie beteen the config file
and the leases file -- what happens if the name used in the config
file for option ### changes name?   But, perhaps that's not worth
worrying about.


Thanks,
John