[PATCH] Enable libstdc++ numeric conversions on Cygwin

Jonathan Wakely jwakely@redhat.com
Thu Nov 12 12:51:00 GMT 2015


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.


I think we should also define a _GLIBCXX11_USE_C99_STDINT macro, to
replace _GLIBCXX_USE_C99_STDINT_TR1 which is used heavily in the C++11
library (e.g. in <future>, <chrono> etc.) and we really want to know
if <stdint.h> types are available in C++11 mode, independent of
whether they are used by TR1 components.

That can be a separate change though.



More information about the Libstdc++ mailing list