On 30 January 2012 03:17, Iain Buclaw <ibuc...@ubuntu.com> wrote: > On 29 January 2012 22:26, Jonathan M Davis <jmdavisp...@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';