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

Re: [Xen-devel] stdbool.h -nostdinc XSA-55 trouble



On Thu, Aug 08, 2013 at 05:12:51PM +0100, Ian Campbell wrote:
> (adding Ian J who did most of XSA-55)
> On Thu, 2013-08-08 at 16:47 +0100, Patrick Welche wrote:
> > On Thu, Aug 08, 2013 at 04:30:06PM +0100, Jan Beulich wrote:
> > > No, according to my checking, the --prefix configure option
> > > listed does not correlate with the directory where the header
> > > is found.
> > 
> > Yes - I think our emails crossed...
> > 
> > The underlying problem is:
> > 
> > Linux:   /usr/lib/gcc/i?86-linux-gnu/n.m/include/stdbool.h
> > NetBSD:  /usr/include/stdbool.h
> 
> The hypervisor side, which is where --nostdinc is used, has it's own
> bool_t in asm/types.h. Perhaps libelf (which is supposed to compile for
> both user and hypervisor space) should be using
> #ifdef __XEN__
> #include <asm/types.h>
> #else
> #include <stdbool.h>
> #endif
> 
> ?
> 
> 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?

AFAIK

char c=0;
!c == 1 (true) (rather than 0xff or ~c or whatever - but this is without
                a "malicious compiler")

so at a glance, this seems OK. (But then I don't know the original
motivation for replacing bools in XSA-55...)

Cheers,

Patrick

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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