debugging frustration

debugging frustration

[Arthur Bergman]

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

Re: debugging frustration

[Mark Williamson]

> 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

Re: debugging frustration

[Anthony Liguori]

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

Re: debugging frustration

[Luciano Miguel Ferreira Rocha]

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

Re: debugging frustration

[Mark Williamson]

> 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

Re: debugging frustration

[Anthony Liguori]

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