At 09:07 01.01.2003 +1100, Andrew Bartlett wrote:
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 :-)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.
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!> 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?
If we have a struct witch is talloced> a also add a view talloc_realloc_*() functions > > talloc_realloc_strdup() ... Why?
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 <[EMAIL PROTECTED]>
