[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

["marc.glisse at normalesup dot org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773

--- Comment #103 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-03 15:52:09 UTC ---
(In reply to comment #102)
> What would help enormously for this would be a complete justification
> for the individual fixes:

Of course. I tried to keep the fixincludes to the minimum.

One fixes the issue with getc/getchar explained above.

One removes the extern "C++" overloads of bsearch/qsort because of PR 2316 :
Solaris is right to have those, but most compilers (wrongly) don't consider
linkage (C vs C++) as part of the type and thus to them Solaris is defining the
same function twice.

One wraps the declarations of pow(*,int) with #ifdef so that they remain
available in C++03 (Solaris is right to have them, section 26.5.6 of the
standard) but they disappear in C++0X (to match section 26.8.9 of N3291).

The first 2 are necessary. I believe the last one is not required (it should
just cause one minor bug in C++0X) and can be reconsidered later if you prefer.

I haven't tested the version of the fixinclude patch attached to the bug, I was
going to do that once I get access to a Solaris 10 (we have one, but it takes a
while to register so I can use it). I wrote the patch on S11, so I also wanted
to get a look at the S10 headers to check for differences.

>   In such a case, it will be easier get Oracle's attention so the issue
>   is also fixed upstream.    (If only C++ 2011, it might be a bit of a
>   tougher ride.)

I guess Oracle will implement C++2011 at some point, no need to push them. The
libstdc++ headers will need adjusting when that happens.

The getc issue is worth reporting upstream though.

> * If this is a libstdc++ requirement not currently demanded by a
>   standard, would there be an alternative way to fix this inside
>   libstdc++?  The reason I'm asking is that the OS headers tend to be a
>   moving target, and you may have to keep updating the fix to keep it
>   working.

I completely agree with this, but it looks hard without fixinclude.

Note that I am not a fixinclude expert and it is possible the fixes could be
written in a less fragile way. And I think one "c_fix_arg" is supposed to be
"select" instead.