[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Fix non-debug build after c/s 23767:80e9fcdaef36


  • To: Tim Deegan <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Mon, 22 Aug 2011 15:18:50 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 22 Aug 2011 07:19:52 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acxg1mm6rYYmL9SFSkG1uX4/ErNaGA==
  • Thread-topic: [Xen-devel] [PATCH] Fix non-debug build after c/s 23767:80e9fcdaef36

On 22/08/2011 15:07, "Tim Deegan" <tim@xxxxxxx> wrote:

> At 15:02 +0100 on 22 Aug (1314025327), George Dunlap wrote:
>> That seems to compile just fine, and obviously makes the code a lot
>> cleaner.  The only thing is that this will still cause functions
>> inside ASSERTS (spin_is_locked() in this case) to be called; I thought
>> part of the reason for having ASSERTs in the debug build only was to
>> reduce the cost of all the checks (the other reason to avoid
>> unnecessary crashes on production builds)?
> 
> How about #define ASSERT(p) do { if (0 && (p)); } while (0) ?

Yes, if this also works then it is preferable.

 -- Keir

> Tim.
> 
>> On Mon, Aug 22, 2011 at 2:35 PM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>>> George,
>>> 
>>> Would something like this work more generically for the non-debug case?
>>> 
>>> #define ASSERT(p) do { if (p); } while (0)
>>> 
>>>  -- Keir
>>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.