From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Welche Subject: Re: stdbool.h -nostdinc XSA-55 trouble Date: Fri, 9 Aug 2013 09:11:25 +0100 Message-ID: <20130809081125.GF290@quark> References: <20130808114945.GG22372@quark> <5203B51402000078000EA534@nat28.tlf.novell.com> <20130808151835.GB870@quark> <5203D59E02000078000EA634@nat28.tlf.novell.com> <20130808154714.GD870@quark> <1375978371.14651.12.camel@kazak.uk.xensource.com> <5204BB6802000078000EA926@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <5204BB6802000078000EA926@nat28.tlf.novell.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: Jan Beulich Cc: Ian Jackson , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, Aug 09, 2013 at 08:50:32AM +0100, Jan Beulich wrote: > That would make sense only if we could also do the same for > stdarg.h, but you'll note that xen/stdarg.h already works around > the same problem on NetBSD and OpenBSD. Going through the > history of xen/stdarg.h also shows that this has been a recurring > problem. It escapes me why they can't just play things the gcc > way if gcc is their compiler. The plan is to use llvm/clang - I haven't tried it, though others already use it as their default compiler (the OS certainly builds). > I.e. either we allow ourselves to use standard headers that are > defining only compiler determined things (in which case we could > also use stdint.h for example), or we don't use _any_ standard > headers. > > > I'd be a bit concerned about the fact that Xen's bool_t is a typedef for > > char, as opposed to the compilers typedef to _Bool which has special > > meaning. It may not matter in practice but might the fact that _Bool > > canonicalises to 0 or 1 vs. 0 or !0 cause something subtle? > > No, that won't work without auditing the code: Non-boolean > expression results will be converted to 0/1 by the compiler when > the lvalue's type is _Bool, but won't when it's bool_t. While that > might seem fine at the first glance as long as consumers of such > variables don't do explicit == 1 checks, this is becoming a problem > when the non-boolean result is 0 modulo 256 (since the conversion > done in the non-_Bool case is a truncation). I'm sorry, I still don't see how I can write code which exhibits the problem case... Could I have a 1A supervision please? Cheers, Patrick