[PATCH] parametric options

[Stefan (metze) Metzmacher]

At 09:07 01.01.2003 +1100, Andrew Bartlett wrote:
>On Wed, 2003-01-01 at 02:44, Stefan (metze) Metzmacher wrote:
> > Hi *,
> >
> > here are the parametric option changes of my big patch...
> >
> > all lp_param_*() functions now take the default value as last parameter
> > this is usefull for all fn's and needed for the enum,bool,int and ulong
> > functions :-)
>
>Is this the best way to do it - if we are going to have a notion of
>defaults, then doing it per-call is just waiting for disaster!  Given
>that we are moving to a 'registration' style of module system (where we
>know at startup what modules we have), I think we really should move
>'parametric options' to a registrations system too.  Indeed, this would
>allow the implement ion of callback syntax checking, which could make
>testparm useful again.

sounds good :-) but I don't know how to handle this when a vfs modules are 
loaded in a per share configuration... (it's easier to discuss details on 
IRC :-)

> > lp_parm_string_list() now use talloc_str_list_make() and
> > talloc_realloc_str_list_make and caches the the result for the called
> > seperator, so if the function is called with the same separator it is not
> > needed to call *_str_list_make()
> >
> > if the function is called with an other separator the old list is free'ed
> >
> > so we didn't get a memory leek if we call:
> >
> > lp_parm_string_list(SNUM(conn), "test","name"," \n\r\t", NULL);
> > lp_parm_string_list(SNUM(conn), "test","name",";,.", NULL);
> > lp_parm_string_list(SNUM(conn), "test","name"," \n\r\t", NULL);
> > lp_parm_string_list(SNUM(conn), "test","name",";,.", NULL);
> > lp_parm_string_list(SNUM(conn), "test","name"," \n\r\t", NULL);
>
>Why do we allow the separator to be changed at all?  The 'normal'
>options in Samba don't all this - I really don't see the need for the
>added complexity.  Furthermore, how are you going to tell SWAT etc about
>this - it should display lists as lists, and not depend on function
>parameters to get it right.  I just don't like the idea that a list
>could change depending on a parameter somebody will always get slightly
>wrong.
>
> > talloc_realloc_str_list_make()
> >
> > a add talloc_free() witch free's the memory of one talloc'ed memory segment
>
>This doesn't seem right - why not just free and replace that talloc
>context?

I only want to free one segment in the talloc context and all other 
talloced memory in this talloc context should not be free'ed!

> > a also add a view talloc_realloc_*() functions
> >
> > talloc_realloc_strdup() ...
>
>Why?

If we have a struct witch is talloced
and strings in the struct are talloced on the same talloc context should be 
replaced, it would be fine to free the memory of the old string...:-)


>Andrew Bartlett


metze
-----------------------------------------------------------------------------
Stefan "metze" Metzmacher <metze at metzemix.de>