[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
marc.glisse at normalesup dot org
gcc-bugzilla@gcc.gnu.org
Wed Aug 3 15:55:00 GMT 2011
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.
More information about the Gcc-bugs
mailing list