On 15/05/14 22:54 -0400, Ed Smith-Rowland wrote:
On 05/15/2014 03:03 PM, Jonathan Wakely wrote:
Here's a finished patch to simplify bits/parse_numbers.h
Tested x86_64-linux. Ed, any objection to this version?
This looks great, thanks!
I committed that to trunk, I'll put it on the 4.9
Here's a finished patch to simplify bits/parse_numbers.h
Tested x86_64-linux. Ed, any objection to this version?
commit 87d26af2fc07f0c45a0a6676161ae1db1d7541b7
Author: Jonathan Wakely jwak...@redhat.com
Date: Wed May 14 16:35:20 2014 +0100
2014-05-15 Ed Smith-Rowland
On 05/15/2014 03:03 PM, Jonathan Wakely wrote:
Here's a finished patch to simplify bits/parse_numbers.h
Tested x86_64-linux. Ed, any objection to this version?
This looks great, thanks!
Having done that should we actually stop using it as suggested in the
bug trail? ;-)
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
OK?
2014-05-14 Ed Smith-Rowland 3dw...@verizon.net
libstdc++/61166 overflow when parse number in
2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland 3dw...@verizon.net:
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
OK?
I understand the reason why the
On 14 May 2014 14:59, Daniel Krügler wrote:
2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland 3dw...@verizon.net:
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
On 05/14/2014 09:59 AM, Daniel Krügler wrote:
2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland 3dw...@verizon.net:
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
On 14 May 2014 15:25, Ed Smith-Rowland wrote:
But in keeping with, say, our extension type traits and such maybe i should
uglify value as well.
No, just derive from std::integral_constant and you get value for free.
You already use integral_constant in that file, so the name value is
already
On 14 May 2014 15:36, Jonathan Wakely wrote:
On 14 May 2014 15:25, Ed Smith-Rowland wrote:
But in keeping with, say, our extension type traits and such maybe i should
uglify value as well.
No, just derive from std::integral_constant and you get value for free.
You already use
On 14/05/14 15:41 +0100, Jonathan Wakely wrote:
On 14 May 2014 15:36, Jonathan Wakely wrote:
On 14 May 2014 15:25, Ed Smith-Rowland wrote:
But in keeping with, say, our extension type traits and such maybe i should
uglify value as well.
No, just derive from std::integral_constant and you get
10 matches
Mail list logo