On Mar 17, 2009, at 10:34 AM, Eric Blake wrote:
I guess I replied inaccurately. The goal is to make AC_C_RESTRICT
(the
existing macro) work correctly.
Gotcha; thanks for the clarification.
Ralf brought up an interesting point - how often do people mix C and
C++
compilers of different origins, and expect things to work? In other
words, it seems to me that the most common use case is that you either
stick with the vendor compiler in all cases (hence the workaround
for the
Sun compiler), or you use gcc in all cases.
I would hope that people stick within a single compiler suite as
well. But I do know that at least some vendors pitch that their C++
compiler is "wholly compatible" with gcc. This is such a moving
target, though, that despite heroic efforts by the compiler vendor,
there are inevitably corner cases that aren't fully compatible (in my
experience).
But if we're mistaken, and
people really DO want to mix vendor C and g++ (or vendor C++ and gcc),
then we must either entirely avoid restrict in C++, or else we must
indeed
make AC_C_RESTRICT perform additional testing inside an
AC_LANG_PUSH([C++])/AC_LANG_POP block, if the configure script does
anything for C++.
FWIW, the case we're talking about is not mixing gcc and pgcc (at
least, the initial reporter didn't report it that way... let's hope
this isn't a giant misunderstanding of the reporter mixing gcc and
pgCC!).
Let me get the config.log from the reporter and let's go from there.
Thanks!
--
Jeff Squyres
Cisco Systems
