Re: VxWorks Patches Back from the Dead!

[rbmj <rbmj at verizon dot net>]

On 8/23/2012 7:54 AM, Paolo Bonzini wrote:
> Il 23/08/2012 13:46, rbmj ha scritto:
> > On 8/23/2012 4:24 AM, Paolo Bonzini wrote:
> > > > Subject: [PATCH 10/10] Make open() call more compatible in gcc/gcov-io.c
> > > >
> > > > In gcc/gcov-io.c, the call to open() only has two arguments. This
> > > > is fine, as long as the system open() is standards compliant.
> > > So you have to add another fixincludes hack, adding a macro indirection
> > > like the one you have for ioctl:
> > >
> > > #define open(a, b, ...)      __open(a, b , ##__VA_ARGS__, 0660)
> > > #define __open(a, b, c, ...) (open)(a, b, c)
> >
> > Again, just not sure about variadic macro compatibility.  If that will
> > work for both c89 and c99 and c++, then that looks good to me.
>
> Yes, GCC has variadic macros as an extension in C89 mode too.  You need
> to experiment a bit with -pedantic and/or -ansi and/or -std=c89, though.

So the variadic macros work for compiling GCC itself.  However, I run 
into problems when compiling libstdc++-v3.  The problem is that 
basic_file.cc defines __basic_file<char>::open(), and the macro is 
substituting for this as well.  So AFAICT the original solution (just 
passing unconditionally) is necessary.  I don't see any pitfalls 
associated with this - do we really care *that* much about passing one 
extra int?

Though it looks weird, it's clearly not unprecedented (as you said, it's 
not the rule, but it has certainly been done in other places).  I don't 
see a way to use a macro that will not break the declaration.  Is there 
a way that a macro can work that I'm missing?

--
rbmj