On Thu, 2010-03-25 at 08:28 +0000, Dave Shield wrote:
> On 24 March 2010 21:21, Magnus Fromreide <[email protected]> wrote:
> > Which version of disabling is the better one:
> 
> In general, I'd prefer either A or B.
> A has the advantage of allowing us to issue suitable
> warning or error messages.
> I.e.
> 
> A')
> ---foo.c---
> #ifdef NETSNMP_DISABLE_FOO
> void foo() { printf("Foo not supported\n"); }
> #else
> void foo() { /* do foo things */ }
> #endif

I am generally against the message as the point is to save space for the
embedded case. I do toy with the thought of making all the replacement
functions inline.

> B has the advantage of smaller code.

Yes, the disadvantage is that it changes the ABI, so you end up with a
libnetsnmp that might be insufficient to run a binary compiled towards a
differently configured but otherwise similar libnetsnmp (same so version
number...)

> I would rather avoid C, as this affects the API,
> and means that #ifdef NETSNMP_DISABLE_FOO
> statements would need to be scattered throughout
> the code.

Yes and no. In the case of snmp_debug the API issue is handled through
the DEBUG_ macros and thus I think C might be viable in that special
case.

> > The real case I have is NETSNMP_DISABLE_DEBUG where
> > I am pondering to either remove or minimize the logging functions.
> 
> But isn't that covered already (using approach B)?
> See the use of NETSNMP_NO_DEBUGGING in
> <net-snmp/library/snmp_debug.h>

No, that only changes the access macros, I am going for the functions
below the macros (e.g. debugmsg).

/MF



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to