In an effort to hide debugging messages, I noticed that xfrd.c undefs
DEBUG after setting it to DEBUG 1. Unless there is something really
fundamental about the gcc c preprocessor I don''t know about, this
doesn''t seem very helpful. Below is a patch that lets the outside user
set debugging instead of hardcoding it.
Also, is there a reason that not having DEBUG in turns dprintf into do
{} while(0) instead of just turning into ""
Cheers
Arthur
-----
CTO @ Fotango Ltd
+447834716919
http://www.fotango.com/
--- xfrd.c.old 2005-02-14 14:17:49.000000000 +0000
+++ xfrd.c 2005-02-14 14:17:58.000000000 +0000
@@ -49,8 +49,6 @@
#include "select.h"
#define MODULE_NAME "XFRD"
-#define DEBUG 1
-#undef DEBUG
#include "debug.h"
/*
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
> Also, is there a reason that not having DEBUG in turns dprintf into do > {} while(0) instead of just turning into ""It makes the macro behave more like a proper statement. e.g. If we try to do: if ( 1 == 2 debug_print("foo!") ) { } It won''t compile, even if debugging is switched off. If we just did "#define debug_print(...)" then this would compile and we''d only notice the error when debugging was switched on. That''s a quite contrived example but basically it keeps the developers honest ;-) Cheers, Mark ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Mark Williamson wrote:>>Also, is there a reason that not having DEBUG in turns dprintf into do >>{} while(0) instead of just turning into "" >> >>The do {} while (0) idiom is commonly used in macros to protect against the following. Say you had a macro that looked like this: #define DEBUG(a, b) if (a > debug_level) printf(b); If you called it like this: if (ptr == NULL) DEBUG(10, "Bad pointer"); else *ptr = 2; What would actually happen is that the else clause would get attached to the if from the DEBUG() statement and you would get very odd behavior. Using do {} while (0) is just the common solution to this problem. It''s not the only solution, but it''s what most people use. Regards, Anthony Liguori>>It makes the macro behave more like a proper statement. e.g. If we try to >>do: >> >>if ( 1 == 2 debug_print("foo!") ) >>{ >> >>} >> >>It won''t compile, even if debugging is switched off. If we just did "#define >>debug_print(...)" then this would compile and we''d only notice the error when >>debugging was switched on. >> >>That''s a quite contrived example but basically it keeps the developers >>honest ;-) >> >>Cheers, >>Mark >> >> >>------------------------------------------------------- >>SF email is sponsored by - The IT Product Guide >>Read honest & candid reviews on hundreds of IT Products from real users. >>Discover which products truly live up to the hype. Start reading now. >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>_______________________________________________ >>Xen-devel mailing list >>Xen-devel@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/xen-devel >> >> >>-- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Mon, Feb 14, 2005 at 09:03:05AM -0600, Anthony Liguori wrote:> Mark Williamson wrote: > > >>Also, is there a reason that not having DEBUG in turns dprintf into do > >>{} while(0) instead of just turning into "" > >> > >> > The do {} while (0) idiom is commonly used in macros to protect against > the following. Say you had a macro that looked like this: > > #define DEBUG(a, b) if (a > debug_level) printf(b); > > If you called it like this: > > if (ptr == NULL) > DEBUG(10, "Bad pointer"); > else > *ptr = 2; > > What would actually happen is that the else clause would get attached to > the if from the DEBUG() statement and you would get very odd behavior. > > Using do {} while (0) is just the common solution to this problem. It''s > not the only solution, but it''s what most people use.Yes, but an empty macro results in the same thing as a do {} while (0) if (ptr == null) ; else *ptr = 2 The only problem is when the macro has some code (AFAIK). Regards, Luciano Rocha ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> if (ptr == null) > ; > else > *ptr = 2 > > The only problem is when the macro has some code (AFAIK).Using a "do {} while(0)" makes the compilation fail if you use the macro somewhere it wouldn''t be valid when debugging enabled. Otherwise, you could end up developing with debugging turned off and not notice the macro is being misused until someone turns it on. Having a dummy statement helps catch this kind of error. Cheers, Mark ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Luciano Miguel Ferreira Rocha wrote:>Yes, but an empty macro results in the same thing as a do {} while (0) > >a = b debug_printf("Message"); compiles cleanly if DEBUG is #define''d as '''' At the end of the day, we''re dealing with a very imperfect system (cpp). My philosophy on debug() macro''s is that they should always map 1-1 to a real function and simply provide that function with __LINE__, __FUNCTION__, and __FILE__. If you''re really concerned about performance, you can #ifdef DEBUG the body of the function and most compilers will correctly do nothing for those calls. If it''s any consolation, the next submission of VM-Tools will have a set of logging functions. I can certainly submit patches to xcs and friends to use these functions.. Regards,>if (ptr == null) > ; >else > *ptr = 2 > >The only problem is when the macro has some code (AFAIK). > >-- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel