Re: strange problem (bug?) with set_inline_types

Hmmm... That's *exactly* what it's doing. It is a bug.

# I tested this with inline_types.

It'll be the same with all the list variables that have a default. Currently that's only inline_types. There are others that should have defaults though...

# This is not a blocking bug, but it may make it hard to configure hypermail.

Yes it could be. The question is how to deal with this properly. This affects:

  {"text_types", &set_text_types, NULL, CFG_LIST,

  {"inline_types", &set_inline_types, INLINE_TYPES, CFG_LIST,

  {"prefered_types", &set_prefered_types, NULL, CFG_LIST,

  {"ignore_types", &set_ignore_types, NULL, CFG_LIST,

  {"show_headers", &set_show_headers, NULL, CFG_LIST,

A quick and sleasy way to correct this would be to set them all to NULL. That is defintely NOT the correct way to do it and is really not a fix. It does not allow for any sane defaults to be set and at some point in the future we will be discussing this problem again.

Warning ... brainstorming...

We could add a boolean variable to struct Config in setup.h that would be (currently) used only for list variables. It would be set in PreConfig() for each of the lists. When the ConfigAddItem() encounters a list it could then check the boolean flag to see if this is the first time a list element has been added since the builtin initialization. If so then we would free any existing memory, re-initialize the list with the new information and set the boolean flag variable to false. Subsequent calls to ConfigAddItem() would find the flag off and add the new element to the list as is done now.

Does this sound reasonable ?

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: kent_at_landfield.com             http://www.landfield.com/
Email: kent_at_nfr.net                   http://www.nfr.net/
Search the Usenet FAQ Archive at http://www.faqs.org/faqs/
Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/