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

[Patrick Welche <prlw1@xxxxxxxxx>]

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

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