This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: "big" integer constants
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Ed Smith-Rowland <3dw4rd at verizon dot net>
- Cc: DJ Delorie <dj at redhat dot com>, libstdc++ at gcc dot gnu dot org
- Date: Wed, 04 Jan 2012 23:06:34 +0100
- Subject: Re: "big" integer constants
- References: <201110290106.p9T16wfS018325@greed.delorie.com> <4EAB5AAE.3010701@oracle.com> <201110290153.p9T1rf0f020227@greed.delorie.com> <4EAB86FF.3040105@verizon.net> <201110290501.p9T51oN8009838@greed.delorie.com> <4F03CBFE.60507@verizon.net>
Hi,
Sorry this took so long. I got busy, then the holidays...
I just changed some big numbers to
std::numeric_limits<std::tr1::uint16_t>::max().
No new testcases. Everything works.
There may have been things beyond the range of the test cases I was
trying to capture but I'm not going to work on that right now.
I'm not super happy with the patch. First, I'm not at all sure we can
safely assume _GLIBCXX_USE_C99_STDINT_TR1 is always defined here,
because otherwise the <cstdint> boils down to nothing and your patch
doesn't work. Please double check.
Besides these boring configury issues, I don't like the idea of using
the max of uint16_t for an unsigned int variable. Maybe it happens to
work on the actual targets supported now, but why not using directly an
uint16_t variable? In any case, if uint16_t isn't actually available per
the above issue, n or m > n instances of it are equally wrong ;)
Paolo.