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

[David W. Hankins]

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, which we treat
as an option space that has a 4-byte code tag and one-byte length
tag (the DHCPv4 options are 1-byte each, and the DHCPv6 options
are 2-bytes each (this is a handy time to support 2-byte code
and length tags, so we did it, in preparation for 4.x work)).

To do that, we had to overcome a kind of comfortable simplicity in
the option space code; to lookup an option definition by code, you
would index an array of 256 elements.  If we wanted to use the
same generic code to process VIVSO options, we would have to have
the two VIV spaces (VIVSO and VIVCO) indexed in an array of 2^32
indices.  Not gonna happen.

So there's a lookup method by simple integer hash now to get from
code back to option definition, and this meant all sorts of bits of
the code had to be touched rather trivially to use the lookup function
rather than direct index on a magic array, and the subsequent cleanup.

One of the implications is that whereas the code used to have
'option-xxx' predefined constants for every option code that was
undefined, the new system would have a simplified array that
contained only the defined options.

Consequently, the parser code that parses "option foo" inspects 'foo'
to see if it is of the form "option-nnn", and dynamically creates a
default definition for it.  Similarly, upon encountering an unknown
option in a packet, one whose code lookup fails on the hash table, a
'unknown-nnn' definition is mocked up.


Somewhere in all of that, it never ocurred to us that someone would
want to refer to a single option code by two different names and
formats (except in different spaces, such as in different site local
or vendor-encapsulated spaces).  Even when the direct array index was
used, it still assumed it would only find at most one option
definition; the later one in the config.


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.

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.

I do know you shouldn't be seeing multiple free's, that's got to be
a bug.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins