"big" integer constants

Ed Smith-Rowland 3dw4rd@verizon.net
Sat Oct 29 04:55:00 GMT 2011


On 10/28/2011 09:53 PM, DJ Delorie wrote:
>> To be honest, I suspect much more than this doesn't work on 16 bit
>> targets, but sure in principle we can change that. Let's ask Ed if he is
>> willing to spend again time on this old work of him... (imho, all those
>> hard coded iteration numbers don't really look right in the first place,
>> just imho)
> Yeah, normally I would just say "don't use those" but in this case,
> gcc is giving an ICE for each of those, since it can't convert the
> integer to a suitable constant.
>
> I suspect there's still something in my port that needs work, but
> those seemed like arbitrary numbers anyway ;-)
>
We could definitely change that limit to 65535U or maybe 
std::numeric_limits<unsigned short>::max() or something.  Is 
sizeof(short) == sizeof(int) consistently on 16 bit targets?  If so I'd 
go for the latter.

These magic numbers exist in gsl and other libraries but the 
hypergeometric functions are especially bad about this.  That's why they 
were dropped from TR29123 (which passed by the way).

I'm actually working on TR29123 hopefully to get in before stage1 ends.  
All it really does is add the special math functions to std:: (minus the 
hypergeometric functions which were regarded as too flaky for 
standardization).  Basically it does some moving of files and some other 
bits.

Ed



More information about the Libstdc++ mailing list