cent and ucent?

[Iain Buclaw]

On 30 January 2012 03:17, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> On 29 January 2012 22:26, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> On Sunday, January 29, 2012 16:26:02 Timon Gehr wrote:
>>> long long is 64-bit on 64-bit linux.
>>
>> Are you sure? I'm _certain_ that we looked at this at work when we were
>> sorting issue with moving some of our products to 64-bit and found that long
>> long was 128 bits. Checking...
>>
>> Well, you're right. Now I'm seriously confused. Hmmm...
>>
>> long double is 128-bit. Maybe that's what threw me off. Well, thanks for
>> correcting me in either case. I thought that I'd had all of that figured out.
>> This is one of the many reasons why I think that any language which didn't
>> define integers according to their _absolute_ size instead of relative size
>> (with the possible exception of some types which vary based on the machine so
>> that you're using the most efficient integer for that machine or are able to
>> index the full memory space) made a huge mistake. C's type scheme is nothing
>> but trouble as far as integral sizes go IMHO. printf in particular is one of
>> the more annoying things to worry about with cross-platform development thanks
>> to varying integer size. Bleh. Enough of my whining.
>>
>> In any case, gcc _does_ define __int128 (
>> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html ), so as far as the
>> question goes, gcc _does_ have 128 bit integers, even if long long isn't 128
>> bits on 64-bit systems.
>>
>> - Jonathan M Davis
>
> Can be turned on via compiler switch:
>
> -m128bit-long-double
>
> or set at the configure stage:
>
> --with-long-double-128
>


Oh wait... I've just re-read that and realised it's to do with reals
(must be 3am in the morning here).



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';