Improving loadparm design to fix bug in configuration reloading

[Matt McCutchen]

On Fri, 2009-01-16 at 19:23 -0800, Wayne Davison wrote:
> On Wed, Jan 14, 2009 at 02:25:33AM -0500, Matt McCutchen wrote:
> > I think I'll take the opportunity to improve the design a bit by
> > actually adding a section structure representing the global values of
> > section parameters to the global structure
> 
> I was thinking we could get rid of the big, must-keep-sorted, statically
> initialized structure and make use of the init_globals() function to set
> the initial values.  However, if you've got something you've done
> already, I'd be glad to consider it.

My proposal to make sDefaults part of the globals (like the &include is
essentially already doing) is independent of whether we initialize the
resulting combination by copying from a statically initialized structure
or by individual assignments in init_globals.  Why do you prefer the
individual assignments?  I think the rigidity of the static
initialization could be an asset in making sure things aren't mistakenly
initialized zero times or twice.

> > I noticed that FN_LOCAL_STRING works differently from the other
> > FN_LOCAL_* in that it goes back to sDefaults if a valid module number
> > is given but the module contains a NULL value.
> 
> It's the only one that is a pointer instead of a value, but I haven't
> yet looked to see if there was a way for a section to get a NULL pointer
> where the sDefault value is non-NULL.

I looked through the Samba history and FN_LOCAL_STRING was like that
from the very beginning, for no evident reason.  I think I'll change it
to work like the others and see if anything breaks.

-- 
Matt