>>>>> On Wed, 23 Mar 2011 12:12:56 +0100, Bart Van Assche <[email protected]>
>>>>> said:
BVA> My two cents: if the ABI or API depends on whether a feature is
BVA> enabled or disabled, we do no longer have an ABI nor an API. This
BVA> conflicts with what I have learned about how to define a shared
BVA> library or DLL ABI or API. So removal of fields from structures or
BVA> adding/removing arguments to functions should go through the normal
BVA> mechanism: only make such changes between releases and not in a
BVA> release itself or via the feature mechanism.
A couple of points:
1) To some extent, someone using the minimalist support is likely not
concerned about the ABI/API stability because they're deliberately
*trying* to remove code (IE, remove ABI/APIs from the standard set).
2) The only place that we're currently using it in a header file is for
the statistics support (shortened):
#ifndef NETSNMP_FEATURE_REMOVE_STATISTICS
u_int snmp_increment_statistic(int which);
#else /* NETSNMP_FEATURE_REMOVE_STATISTICS */
/* allow code to continue referencing API */
#define snmp_increment_statistic(X)
#endif
In this case, the API is really still there, just implemented as
macros that do nothing. This is done because it's clearer than doing
a bunch of #ifdefs in the code itself every time there is a call to
the similar function.
--
Wes Hardaker
Please mail all replies to [email protected]
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
