On Thu, 2012-04-26 at 21:41 -0400, Robert Story wrote: > On Thu, 26 Apr 2012 21:56:11 +0200 Niels wrote: > NB> Den 26-04-2012 15:41, Robert Story skrev: > NB> > An IRC user reports an issue with net-snmp-config.h: > NB> > > NB> > "when building against net-snmp, i have to modify net-snmp-config.h to > NB> > #define HAVE_DMALLOC_H 0, otherwise net-snmp-includes.h fails saying > NB> > HAVE_DMALLOC_H is not defined" > NB> > > NB> > This change was made in commit 3a423609cafaca7b729873295bcac3bf6cfb2bda, > NB> > in 2002. > NB> > > NB> > -#ifdef HAVE_DMALLOC_H > NB> > +#if HAVE_DMALLOC_H > NB> > > NB> > I thought that, since this macro comes from a configure check, that it > NB> > is only defined when true, and would be undefined instead of having a 0 > NB> > value. > NB> > > NB> > There are several other defines in this file that were also changed to > NB> > "#if"... Is there a good reason no to use "#ifdef"? > NB> > NB> But I gather this holds for all other HAVE_xxx symbols too, and they > NB> seem not to cause any problems? We use #if HAVE_xxx almost exclusively > NB> in the source. What compiler is that, who complains about this. > > I think he was using net-snmp with another package, so perhaps the other > package had the others defined from their own configure tests? They didn't say > what compiler.. I know there is a compiler flag for catching undefined > macros.. could be he has that enabled, or it's a compilier that defaults to > treating it as an error. > > In our source tree: > > $ header include/ "#if "| wc -l > 77 > > $ header include/ "#ifdef "| wc -l > 394 > > $ code "#if "|wc -l > 2283 > > $ code "#ifdef "|wc -l > 1557 > > > NB> But in principle, of course, it would be more correct to use #ifdef > > I googled to see if there was a definitive answer, and there doesn't seem to > be consensus on the issue. > > > I did find that other people have this problem too.. For example, in the > asterisk source (http://www.asterisk.org/doxygen/trunk/agent_8c-source.html): > > > 00021 /* [...] > 00026 * Also netsnmp has an improper check for HAVE_DMALLOC_H, using > 00027 * #if HAVE_DMALLOC_H instead of #ifdef HAVE_DMALLOC_H > 00028 * As a countermeasure we define it to 0, however this will fail > 00029 * when the proper check is implemented. > 00030 */ > [...] > 00046 #ifndef HAVE_DMALLOC_H > 00047 #define HAVE_DMALLOC_H 0 /* XXX we shouldn't do this */ > 00048 #endif > > And a message from our illustrious leader on this very topic (albeit in a > different header file): > > http://groups.google.com/group/mailing.unix.net-snmp-coders/browse_thread/thread/ea9d81aa2b71cbe1
The obvious solution is to stop leaking defines all over the place - I think it is quite bad that we define all that HAVE_ crap in public header files as it outside of our namespace. The big question is how to stop leaking. /MF ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
