Note that there are some explanatory texts on larger screens.

plurals
  1. POArchitectures/ABIs where sizeof(long long) != 8
    primarykey
    data
    text
    <p>In x86/amd64 world <code>sizeof(long long)</code> is 8.</p> <p>Let me quote quite insightful 8 year old <a href="http://gcc.gnu.org/ml/gcc/2004-03/msg01251.html">mail by Zack Weinberg</a>:</p> <blockquote> <p>Scott Robert Ladd writes:</p> <blockquote> <p>On a 64-bit AMD64 architecture, GCC defines <code>long long</code> as 64 bits, the same as a <code>long</code>.</p> <p>Given that certain 64-bit instructions (multiply) produce 128-bit results, doesn't it seem logical the <code>long long</code> be defined as 128 bits?</p> </blockquote> <p>No, for two reasons:</p> <ol> <li><p>The choice of 64-bit '<code>long long</code>' has been written into the ABI of most LP64-model operating systems; we can't unilaterally change it.</p></li> <li><p>This is actually the correct choice, as it removes the aberration that makes '<code>long</code>' not the widest basic integral type. There is lots and lots of code in the wild written to the assumption that <code>sizeof(long) &gt;= sizeof(size_t)</code> - this is at least potentially broken by ABIs where long long is wider than long.</p> <p>(This was an extremely contentious topic during the development of C99. As best as I can tell from an outside perspective, '<code>long long</code>' was only standardized due to pressure from Microsoft who can't for some reason implement an LP64 model. Everyone else hated the idea of making '<code>long</code>' not necessarily the widest basic integral type.)</p></li> </ol> <p>Best current practice appears to be to provide an "extended integral type" <code>__int128</code>. This doesn't have the problems of '<code>long long</code>' because it's not a <em>basic</em> integral type (in particular, it cannot be used for <code>size_t</code>).</p> <p>zw</p> </blockquote> <hr> <p><code>long long</code> is widest <strong>basic</strong> integral type. It's 64-bit long on any non-dead-old architectures/ABIs I know. This allows for going with simple cross-platform (well, at least for many 32/64-bit architectures) typedefs:</p> <pre><code>typedef char s8; typedef unsigned char u8; typedef short s16; typedef unsigned short u16; typedef int s32; typedef unsigned int u32; typedef long long s64; typedef unsigned long long u64; </code></pre> <p>that are nicer than <code>intXX_t</code>, because:</p> <ul> <li>they use same underlying type for 64-bit integers on different platforms</li> <li>allows avoiding verbose <code>PRId64</code>/<code>PRIu64</code><br> (I am well aware that Visual C++ supports <code>%lld</code>/<code>%llu</code> only since 2005)</li> </ul> <p>But how portable this solution is can be expressed by answers to the following question.</p> <hr> <p><strong>What are the architectures/ABIs where <code>sizeof(long long) != 8</code>?</strong></p> <p>If you cannot provide any recent/modern ones, then go ahead with the old ones, but only if they are still in use.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload