Re: stdbool.h -nostdinc XSA-55 trouble

[Patrick Welche <prlw1@cam.ac.uk>]

On Fri, Aug 09, 2013 at 04:13:29PM +0100, Tim Deegan wrote:
> At 09:40 +0100 on 09 Aug (1376041248), Jan Beulich wrote:
> > >>> On 09.08.13 at 10:33, Patrick Welche <prlw1@cam.ac.uk> wrote:
> > > On Fri, Aug 09, 2013 at 09:11:25AM +0100, Patrick Welche wrote:
> > >> 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).
> > > 
> > > This part seems to already be answered in xen/arch/x86/Rules.mk:
> > > 
> > > # Solaris grabs stdarg.h and friends from the system include directory.
> > > # Clang likewise.
> > > 
> > > -> compiler rather than OS check?
> > 
> > Both, as is already done there. Albeit I don't know clang at all,
> > in particular whether it - like gcc - makes its own header versions
> > available somewhere.
> 
> That rune is wrong for clang, AFAICT (even though I bet I wrote it). 
> On my local debian/linux system, clang gets stdarg, stdbool &c from
> /usr/include/clang/3.0/include/
> 
> Figuring out how to make clang tell me that path in a scriptable way
> might be interesting though.  I'll look at it next week. 

And just for consistency, a clang on NetBSD installation has it in
/usr/include...

Cheers,

Patrick