This is the mail archive of the
mailing list for the libstdc++ project.
Re: V3 PATCH: numeric_limits<> support, fix PR/3865
Neil Booth <email@example.com> writes:
| Gabriel Dos Reis wrote:-
| > | Are
| > | they going to be enabled only for C++ so C doesn't have to carry the
| > | baggage?
| > The __WCHAR_UNSIGNED__ sign is defined only in C++ as explained.
| > However other information about type precision and floating point
| > format as defined both in C and C++. Why do you think they are
| > unnecessary in C? For proper floating point support in C99 and C++
| > (i.e. without mismatch), both languages library supports have to share
| > the same information.
| Does Glibc not get it right at present?
Maybe yes, maybe no. I don't even think Glibc provides full support
(i.e. including non-IEEE plateforms) for floating point systems on the
The world does not turn around Glibc. On non-glibc systems we have to
duplicate the configuration information -- which are already inside
the compiler. With all the disavatanges -- and the recent breakage
is an example what one can get with duplicating and second-guessing
something the compiler already knows of.
If it is an issue for you to have those macros defined in C, please
feel free to surround their definitions with
if (clk_language == cl_cpluscplus), but do leave them defined for C++.
(Although leaving them also defined for C helps minimize discrepency).
We need them to match the compiler's view. Since the compiler does
already know them, we want the compiler to tell us their values.
| > | Signedness of wchar_t is easily tested with if () or #if, for example;
| > | a macro is quite redundant.
| > wchar_t is a keyword in C++, how do you easily test its signness with
| > if(0 or #if at compile-time and having that information in accordance
| > with the compiler's own idea?
| if (L'\0' - 1 < 0)
That doesn't work with -fshort-wchar.
Also, that assumes CPP uses (or emulates) the target's integer system
to do calculations. Is that the case?