On 12/11/15 11:40 +0000, Jonathan Wakely wrote:
On 18/09/15 12:01 -0400, Jennifer Yao wrote:
Forgot to include the patch.
On Fri, Sep 18, 2015 at 11:17 AM, Jennifer Yao
<jenny.hyphen.fa@gmail.com> wrote:
A number of functions in libstdc++ are guarded by the _GLIBCXX_USE_C99
preprocessor macro, which is only defined on systems that pass all of
the checks for a large set of C99 functions. Consequently, on systems
which lack any of the required C99 facilities (e.g. Cygwin, which
lacks some C99 complex math functions), the numeric conversion
functions (std::stoi(), std::stol(), std::to_string(), etc.) are not
defined—a rather silly outcome, as none of the numeric conversion
functions are implemented using C99 math functions.
This patch enables numeric conversion functions on the aforementioned
systems by splitting the checks for C99 support and defining several
new macros (_GLIBCXX_USE_C99_STDIO, _GLIBCXX_USE_C99_STDLIB, and
_GLIBCXX_USE_C99_WCHAR), which replace the use of _GLIBCXX_USE_C99 in
#if conditionals where appropriate.
(Coming back to this now that Jennifer's copyright assignment is
complete...)
Splitting the _GLIBCXX_USE_C99 macro into more fine-grained macros for
separate features is definitely the right direction.
However your patch also changes the configure tests to use -std=c++0x
(which should be -std=c++11, but that's a minor point). On an OS that
only makes the C99 library available conditionally that will mean that
configure determines that C99 library features are supported, but we
will get errors if we try to use those features in C++03 parts of the
library.
I think a more complete solution is to have two sets of configure
tests and two sets of macros, so that we define _GLIBCXX_USE_C99_STDIO
when C99 stdio is available unconditionally, and define
_GLIBCXX11_USE_C99_STDIO when it's available with -std=c++11.
Then in the library code we can check _GLIBCXX_USE_C99_STDIO if we
want to use C99 features in C++03 code, and check
_GLIBCXX11_USE_C99_STDIO if we want to use the features in C++11 code.
That should still solve the problem for the numeric conversion
functions, because they are defined in C++11 and so would check
_GLIBCXX11_USE_C99_STDIO, which will be defined for newlib.
Other pieces of the library, such as locales, will use
_GLIBCXX_USE_C99_STDIO and that might still be false for newlib (and
for other strict C libraries like the Solaris and FreeBSD libc).
I will make the changes to acinclude.m4 to duplicate the tests, so we
test once with -std=c++98 and once with -std=c++11, and then change
the library to check either _GLIBCXX_xxx or _GLIBCXX11_xxx as
appropriate.
Here's a patch implementing my suggestion.
The major changes since Jennifer's original patch are in acinclude.m4,
to do the autoconf tests once with -std=c++98 and again with
-std=c++11, and in include/bits/c++config to define the
_GLIBCXX_USE_C99_XXX macros according to either _GLIBCXX98_USE_CXX_XXX
or _GLIBCXX11_USE_CXX_XXX, depending on the standard mode in effect
when the file is included.
Because those new definitions in bits/c++config are unconditional I
had to adjust a few #ifdef tests to use #if instead.
I also removed the changes to GLIBCXX_CHECK_C99_TR1, so that there are
no changes to the macros used for the TR1 library. As a follow-up
change I will add a test for <stdint.h> to GLIBCXX_ENABLE_C99 and
change several C++ headers to stop using the TR1 macros.
This passes all tests on powerpc64le-linux, I'll also try to test on
DragonFly and FreeBSD.
Does this look good to everyone?
One downside of this change is that we introduce some (hopefully safe)
ODR violations, where inline functions and templates that depend on
_GLIBCXX_USE_C99_FOO might now be defined differently in C++98 and
C++11 code. Previously they had the same definition, even though in
C++11 mode the value of the _GLIBCXX_USE_C99_FOO macro might have been
sub-optimal (i.e. the C99 features were usable, but the macro said
they weren't). Those ODR violatiosn could be avoided if needed, by
always using the _GLIBCXX98_USE_C99_FOO macro in code that can be
included from either C++98 or C++11. We could still use the
_GLIBCXX11_USE_C99_FOO macro in pure C++11 code (such as the numeric
conversion functions) and get most of the benefit of this change.