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