From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: [PATCH] minios: Fix incorrect {, un}likely() definitions Date: Mon, 30 Jun 2014 18:00:42 +0200 Message-ID: <20140630160042.GN5027@type> References: <1404143835-2151-1-git-send-email-andrew.cooper3@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1404143835-2151-1-git-send-email-andrew.cooper3@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Stefano Stabellini , Xen-devel List-Id: xen-devel@lists.xenproject.org Andrew Cooper, le Mon 30 Jun 2014 16:57:15 +0100, a =E9crit : > As identified in e5545fb6, likely() and unlikely() must convert their > expressions to booleans before comparing to 1 or 0, to avoid truncation > issues. > = > While editing this file, add inclusion guards. > = > Signed-off-by: Andrew Cooper > CC: Stefano Stabellini > CC: Samuel Thibault Acked-by: Samuel Thibault > --- > extras/mini-os/include/compiler.h | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > = > diff --git a/extras/mini-os/include/compiler.h b/extras/mini-os/include/c= ompiler.h > index e35c9d5..4188277 100644 > --- a/extras/mini-os/include/compiler.h > +++ b/extras/mini-os/include/compiler.h > @@ -1,5 +1,10 @@ > +#ifndef __MINIOS_COMPILER_H_ > +#define __MINIOS_COMPILER_H_ > + > #if __GNUC__ =3D=3D 2 && __GNUC_MINOR__ < 96 > #define __builtin_expect(x, expected_value) (x) > #endif > -#define unlikely(x) __builtin_expect((x),0) > -#define likely(x) __builtin_expect((x),1) > +#define unlikely(x) __builtin_expect(!!(x),0) > +#define likely(x) __builtin_expect(!!(x),1) > + > +#endif /* __MINIOS_COMPILER_H_ */ > -- = > 1.7.10.4 > = -- = Samuel > No manual is ever necessary. May I politely interject here: BULLSHIT. That's the biggest Apple lie of a= ll! (Discussion in comp.os.linux.misc on the intuitiveness of interfaces.)