Re: AC_C_RESTRICT

[Jeff Squyres]

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