> DS> [As an aside - in order to implement this, I needed to tweak the
> DS> 'read_config' call to return a success/failure indication, rather
> DS> than void. In the attached patch, this is done using a new internal
> DS> '_read_config()' call. It might be cleaner to change the
> DS> read_config() call itself, though this would change the API
> DS> slightly. I'm not sure whether this would break existing code, or
> DS> whether 'read_config' is regarded as part of the main public API (as
> DS> opposed to the internal public API). Thoughts?
> DS> ]
>
> Changing the api is some what confusing since the returning something
> that wasn't returned before already won't be checked on in any of the
> existing code. But new warnings may appear I suppose.
That's the only reason that I'd even contemplate changing the return value
of an existing routine. Given that it currently doesn't return anything,
no existing code will be checking the (non-existant) return value.
So tweaking the API to return a success/failure indication should not
break any existing code - the worst it could do would be to introduce
warnings.
The reason I'd like to make this change is that it's not just the call
"read_config()" that might be affected. It would be useful if *all*
the internal config processing routines (i.e. everything bar 'read_configs'
and 'read_premib_configs') returned an indication of success/failure.
The trigger for this was my first experiments with the "include" directive,
which failed to load the specified file, but gave no indication of this.
It was only when I turned on the relevant debugging token, that I
realised the problem.
It would seem sensible if
include notfound-on-search-path.conf
reported some form of warning,
but the call 'read_config_files_of_type()' has no way of detecting this.
None of these calls are part of the public API as documented in
config_api(3), and typically wouldn't be called by user applications
or MIB modules.. And the effect of the change of existing code
that *did* use them directly would probably be minimal.
So it doesn't feel too out-of-the-question to tweak these
"internal" routines to return an indication of whether any of the
named file(s) had been found and processed. I'd argue that
the benefits here would outweigh the cost.
(The alternative would be to have yet another set of wrapper
routines, but I'm not convinced that is either worth it or necessary)
Dave
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
