looking for more project ideas

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Collier-Brown wrote:
>   Strongly agree!
>   Logically the checks on the parameters should be when they're
> initially set, so the code is "right there". With it in
> a different file entirely, it's unlikely to be fixed if.
> the loading changes.
> 
>   After pruning the parameters, one might see code like
> 
> {"map hidden", P_BOOL, P_LOCAL, &sDefault.bMap_hidden, set_map_hidden,    
>     NULL, FLAG_ADVANCED | FLAG_SHARE | FLAG_GLOBAL},
> ---
> 
> static BOOL set_map_hidden(int snum, const char *pszParmValue,
>         char **ptr) {
>     if (*ptr == True && (sDefault.iCreate_mask & 0111) {
>         complain_bitterly (;-))
>     }
>     else {
>         sDefault.bMap_hidden = *ptr;
>     }
>     return True;
> }
> 
> Hopefully when someone comes to change map hidden, one will
> notice it's set in a handler and modify that (;-))

That's a  better approach I think.  However, it won't
catch a case where the create mask is set later in the
file.  You almost would have to code reciprocal checks.
The addition of the set_map_hidden() and for a significant
number of other parameters would really make loadparm.c
blow up.

We have as one project "Solve the parameter bloat problem" :-)
I'm thinking that maybe this type of consistency checking
could be one of the requirements for a new system.  Every band
aid that we apply to the current systems seems to be too
intrinsically tied to loadparm.c and the parser.  The consistency
checks should be logically independent I think.

I'm not completely convinced 'm right on this one though.
Just sort of a knee jerk reaction.


cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEVhQAIR7qMdg1EfYRAqtIAKDSjAdz+dtOL47+dzYeSkOV9fNW3QCdHPke
6tRoCb4NidL0Vu9ls0OmMm8=
=P46S
-----END PGP SIGNATURE-----