blocks|key|2714507|text|除了char之外，这些标准没有提到任何整数类型的确切大小。通常，32位系统上的long是32位，64位系统上是64位.|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2714508|但是，标准确实指定了最小大小。来自C标准+5.2.4.2.1节|2714509|1下列数值应由适合于#if预处理指令的常量表达式取代。此外，除CHAR_BIT和MB_LEN_MAX外，以下内容应替换为具有与根据整数提升转换的相应类型的对象的表达式相同类型的表达式。其实现定义的值应等于或大于所示值(绝对值)，并具有相同的符号。。
..。|blockquote|BOLD|2714510|long+int类型对象的最小值
LONG_MIN+-2147483647+//−(2%5E31−1)|unordered-list-item|2714511|long+int类型对象的最大值
LONG_MAX+%2B2147483647+//+2%5E31−1|2714512|这意味着long+int必须至少为32位，但可能更大。在CHAR_BIT为8的机器上，最小字节大小为4。但是，在机器上，例如CHAR_BIT等于16时，long+int可以是2字节长。|2714513|这是一个现实世界的例子。关于下列代码：|2714514|#include+<stdio.h>

int+main+()
{
++++printf("sizeof(long)+=+%25zu\n",+sizeof(long));
++++return+0;
}|code-block|syntax|javascript|2714515|在Debian+7+i686上的输出：|2714516|尺寸(长)=4|2714517|CentOS+7+x64上的输出：|2714518|尺寸(长)=8|2714519|所以不，你不能对尺寸做任何假设。如果需要特定大小的类型，可以使用stdint.h中定义的类型。它定义了以下类型：|2714520|int8_t：签名8位|2714521|uint8_t：无符号8位|2714522|int16_t：签名16位|2714523|uint16_t：无符号16位|2714524|int32_t：签名32位|2714525|uint32_t：无符号32位|2714526|int64_t：签名64位|2714527|uint64_t：无符号64位|2714528|标准的7.20节描述了stdint.h标头，7.20.1.1节中有精确的宽度类型。标准声明这些类型防御是可选的，但它们存在于大多数实现中。|2714529|entityMap|0|LINK|mutability|MUTABLE|url|http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf^0|2|4|13|4|0|H|3|0|0|A|3|V|8|14|A|2K|V|0|0|8|H|8|0|0|8|H|8|0|4|8|S|8|1Q|8|24|8|0|0|0|0|0|0|0|W|8|0|0|6|0|0|7|0|0|7|0|0|8|0|0|7|0|0|8|0|0|7|0|0|8|0|B|8|0^^$0|@$1|2|3|4|5|6|7|1Z|8|@$9|20|A|21|B|C]|$9|22|A|23|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|24|8|@]|D|@$9|25|A|26|1|27]]|E|$]]|$1|H|3|I|5|J|7|28|8|@$9|29|A|2A|B|C]|$9|2B|A|2C|B|C]|$9|2D|A|2E|B|C]|$9|2F|A|2G|B|K]]|D|@]|E|$]]|$1|L|3|M|5|N|7|2H|8|@$9|2I|A|2J|B|C]|$9|2K|A|2L|B|C]]|D|@]|E|$]]|$1|O|3|P|5|N|7|2M|8|@$9|2N|A|2O|B|C]|$9|2P|A|2Q|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|2R|8|@$9|2S|A|2T|B|C]|$9|2U|A|2V|B|C]|$9|2W|A|2X|B|C]|$9|2Y|A|2Z|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|30|8|@]|D|@]|E|$]]|$1|U|3|V|5|W|7|31|8|@]|D|@]|E|$X|Y]]|$1|Z|3|10|5|6|7|32|8|@]|D|@]|E|$]]|$1|11|3|12|5|J|7|33|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|34|8|@]|D|@]|E|$]]|$1|15|3|16|5|J|7|35|8|@]|D|@]|E|$]]|$1|17|3|18|5|6|7|36|8|@$9|37|A|38|B|C]]|D|@]|E|$]]|$1|19|3|1A|5|N|7|39|8|@$9|3A|A|3B|B|C]]|D|@]|E|$]]|$1|1B|3|1C|5|N|7|3C|8|@$9|3D|A|3E|B|C]]|D|@]|E|$]]|$1|1D|3|1E|5|N|7|3F|8|@$9|3G|A|3H|B|C]]|D|@]|E|$]]|$1|1F|3|1G|5|N|7|3I|8|@$9|3J|A|3K|B|C]]|D|@]|E|$]]|$1|1H|3|1I|5|N|7|3L|8|@$9|3M|A|3N|B|C]]|D|@]|E|$]]|$1|1J|3|1K|5|N|7|3O|8|@$9|3P|A|3Q|B|C]]|D|@]|E|$]]|$1|1L|3|1M|5|N|7|3R|8|@$9|3S|A|3T|B|C]]|D|@]|E|$]]|$1|1N|3|1O|5|N|7|3U|8|@$9|3V|A|3W|B|C]]|D|@]|E|$]]|$1|1P|3|1Q|5|6|7|3X|8|@$9|3Y|A|3Z|B|C]]|D|@]|E|$]]|$1|1R|3|-4|5|6|7|40|8|@]|D|@]|E|$]]]|1S|$1T|$5|1U|1V|1W|E|$1X|1Y]]]]

The standards say nothing regarding the exact size of any integer types aside from <code>char</code>. Typically, <code>long</code> is 32-bit on 32-bit systems and 64-bit on 64-bit systems.

The standard does however specify a minimum size. From section 5.2.4.2.1 of the <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf" rel="noreferrer">C Standard</a>:

<blockquote>
 1 The values given below shall be replaced by constant expressions
 suitable for use in <code>#if</code> preprocessing directives. Moreover, 
 except for <code>CHAR_BIT</code> and <code>MB_LEN_MAX</code>, the following shall be 
 replaced by expressions that have the same type as would an
 expression that is an object of the corresponding type converted
 according to the integer promotions. Their implementation-defined
 values shall be equal or greater in magnitude (absolute value) to
 those shown, with the same sign.
 
 ...
 
 <ul>
 <li>minimum value for an object of type <code>long int</code> 
 
 <code>LONG_MIN</code> -2147483647 // −(2^31−1) </li>
 <li>maximum value for an object of type <code>long int</code> 
 
 <code>LONG_MAX</code> +2147483647 // 2^31−1</li>
 </ul>
</blockquote>

This says that a <code>long int</code> must be a minimum of 32 bits, but may be larger. On a machine where <code>CHAR_BIT</code> is 8, this gives a minimum byte size of 4. However on machine with e.g. <code>CHAR_BIT</code> equal to 16, a <code>long int</code> could be 2 bytes long.

Here's a real-world example. For the following code:

<pre><code>#include &lt;stdio.h&gt;

int main ()
{
 printf("sizeof(long) = %zu\n", sizeof(long));
 return 0;
}
</code></pre>

Output on Debian 7 i686:

<blockquote>
 sizeof(long) = 4
</blockquote>

Output on CentOS 7 x64:

<blockquote>
 sizeof(long) = 8
</blockquote>

So no, you can't make any assumptions on size. If you need a type of a specific size, you can use the types defined in <code>stdint.h</code>. It defines the following types:

<ul>
<li><code>int8_t</code>: signed 8-bit</li>
<li><code>uint8_t</code>: unsigned 8-bit</li>
<li><code>int16_t</code>: signed 16-bit</li>
<li><code>uint16_t</code>: unsigned 16-bit</li>
<li><code>int32_t</code>: signed 32-bit</li>
<li><code>uint32_t</code>: unsigned 32-bit</li>
<li><code>int64_t</code>: signed 64-bit</li>
<li><code>uint64_t</code>: unsigned 64-bit</li>
</ul>

The <code>stdint.h</code> header is described in section 7.20 of the standard, with exact width types in section 7.20.1.1. The standard states that these typedefs are optional, but they exist on most implementations.

blocks|key|371859|text|使用代码sizeof(long+int)并检查大小。它将给出您当前工作的系统上长int的大小(以字节为单位)。你的问题的答案是否定的。它在C或POSIX或任何地方都没有得到保证。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|371860|entityMap^0|4|G|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Use code <code>sizeof(long int)</code> and check the size. It will give you the size of long int in bytes on the system you're working currently. The answer of your question in particular is NO. It is nowhere guaranteed in C or in POSIX or anywhere.

blocks|key|2714538|text|不，无论是C标准还是POSIX都不能保证这一点，实际上大多数类似Unix的64位平台有64位(8字节)+long。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2714539|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models^0|1G|4|R|F|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

No, neither the C standard nor POSIX guarantee this and in fact <a href="https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models" rel="noreferrer">most Unix-like 64-bit platforms</a> have a 64 bit (8 byte) <code>long</code>.

blocks|key|371923|text|正如@delnan所指出的那样，POSIX实现将long和int的大小保持为未指定的大小，并且在32位和64位系统之间常常存在差异。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|371924|long的长度主要与硬件相关(通常与CPU上的数据寄存器大小相匹配，有时与其他软件相关的问题，如OS设计和ABI接口)。|BOLD|371925|为了让您放心，sizeof不是一个函数，而是一个编译器指令*，所以您的代码在使用sizeof时不使用操作--这与编写数字一样，只是它是可移植的。|371926|用途：|371927|sizeof(long+int)|code-block|syntax|javascript|371928|*正如Dave在注释中指出的那样，在编译期间(例如使用可变长度数组)无法计算值时，将在运行时计算sizeof。|371929|另外，正如在另一个注释中指出的，sizeof考虑了实现所使用的填充和对齐，这意味着实际使用的字节可能与内存中的大小不同(这在位移位时可能很重要)。|371930|如果要查找特定字节大小的变量，请考虑使用字节数组，或者(我假设支持)+C99在stdint.h中定义的类型--正如@dbush所建议的那样。|371931|entityMap^0|O|4|T|3|0|0|4|A|2|0|7|6|14|6|0|0|0|1C|6|0|G|6|0|13|8|0^^$0|@$1|2|3|4|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|H]]|D|@]|E|$]]|$1|I|3|J|5|6|7|19|8|@$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1E|8|@]|D|@]|E|$]]|$1|M|3|N|5|O|7|1F|8|@]|D|@]|E|$P|Q]]|$1|R|3|S|5|6|7|1G|8|@$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|T|3|U|5|6|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|V|3|W|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1P|8|@]|D|@]|E|$]]]|Y|$]]

As pointed out by @delnan, POSIX implementations keep the size of <code>long</code> and <code>int</code> as unspecified and it often differs between 32 bit and 64 bit systems.

The length of <code>long</code> is mostly hardware related (often matching the size of data registers on the CPU and sometimes other software related issues such as OS design and ABI interfacing).

To ease your mind, <code>sizeof</code> isn't a function, but a compiler directive*, so your code isn't using operations when using <code>sizeof</code> - it's the same as writing a number, only it's portable.

use:

<pre><code>sizeof(long int)
</code></pre>

* As Dave pointed out in the comments, <code>sizeof</code> will be computed at runtime when it's impossible to compute the value during compilation, such as when using variable length arrays.

Also, as pointed out in another comment, <code>sizeof</code> takes into consideration the padding and alignment used by the implementation, meaning that the actual bytes in use could be different then the size in memory (this could be important when bit shifting).

If you're looking for specific byte sized variables, consider using a byte array or (I would assume to be supported) the types defined by C99 in <code>stdint.h</code> - as suggested by @dbush.

blocks|key|369946|text|编译器根据硬件和操作系统的类型确定大小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|369947|因此，不应对规模作出假设。|369948|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The compiler determines the size based on the type of hardware and OS. 

So, assumptions should not be made regarding the size.

blocks|key|369962|text|当我们第一次在ICL+39硬件上实现C时，我们采用了它的标准，并将数据类型映射到该机器体系结构上的自然表示，即short+=+32位，int+=+64位，long+=+128位。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|369963|但是我们发现没有真正的C应用程序工作；它们都假设映射short+=+16，int+=+32，long+=+64，我们必须修改编译器来支持它。|369964|因此，无论官方标准怎么说，多年来，每个人都集中在long+=+64位上，而且它不太可能改变。|369965|entityMap^0|1J|5|1V|3|25|4|0|Q|5|11|3|1A|4|0|O|4|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|K|$]]

When we first implemented C on ICL Series 39 hardware, we took the standard at its word and mapped the data types to the natural representation on that machine architecture, which was <code>short</code> = 32 bits, <code>int</code> = 64 bits, <code>long</code> = 128 bits. 

But we found that no serious C applications worked; they all assumed the mapping <code>short</code> = 16, <code>int</code> = 32, <code>long</code> = 64, and we had to change the compiler to support that. 

So whatever the official standard says, for many years everyone has converged on <code>long</code> = 64 bits and it's not likely to change.

blocks|key|2714729|text|标准没有提到long+int的大小，因此它取决于您正在使用的环境。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2714730|要在您的环境中获得long+int的大小，可以使用sizeof运算符并获得long+int的大小。有点像|2714731|sizeof(long+int)|code-block|syntax|javascript|2714732|C标准只要求关于类型大小的以下几点|blockquote|2714733|int+>=+16位，|unordered-list-item|2714734|长>=+32位，|2714735|长(自C99)+>=+64位|2714736|<=尺寸(短)+<=尺寸(Int)(Int)+<=尺寸(长)+<=尺寸(长)|2714737|(Char)+==+1型|2714738|CHAR_BIT+>=+8|2714739|其余的是定义的实现，因此，如果遇到int具有18/24/36/60位、补码符号形式、(+char+)+==大小(短)+==大小(Int)+==+some+of+(+long+)+==+4、48位长或9位字符的系统，这并不奇怪，因为标准委员会关心并列出了C标准支持的平台。|2714740|上面关于长int的观点是完全错误的。大多数Linux/Unix实现都定义为64位类型，但在Windows中只有32位，因为它们使用不同的数据模型(请看这里的表64位计算)，这与32位或64位OS版本无关。|2714741|来源|2714742|entityMap|0|LINK|mutability|MUTABLE|url|http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf|1|https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models|2|https://www.quora.com/Why-do-long-int-and-char*-take-up-different-amount-of-space-in-32-bit-and-64-bit-machines^0|6|8|0|2|0|0|9|8|P|6|11|8|0|0|0|0|0|0|0|0|0|0|27|5|1|0|0|2|2|0^^$0|@$1|2|3|4|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|D|@$9|1N|A|1O|1|1P]]|E|$]]|$1|F|3|G|5|6|7|1Q|8|@$9|1R|A|1S|B|C]|$9|1T|A|1U|B|C]|$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|1X|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|O|7|1Y|8|@]|D|@]|E|$]]|$1|P|3|Q|5|R|7|1Z|8|@]|D|@]|E|$]]|$1|S|3|T|5|R|7|20|8|@]|D|@]|E|$]]|$1|U|3|V|5|R|7|21|8|@]|D|@]|E|$]]|$1|W|3|X|5|R|7|22|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|R|7|23|8|@]|D|@]|E|$]]|$1|10|3|11|5|R|7|24|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|25|8|@]|D|@]|E|$]]|$1|14|3|15|5|6|7|26|8|@]|D|@$9|27|A|28|1|29]]|E|$]]|$1|16|3|17|5|6|7|2A|8|@]|D|@$9|2B|A|2C|1|2D]]|E|$]]|$1|18|3|-4|5|6|7|2E|8|@]|D|@]|E|$]]]|19|$1A|$5|1B|1C|1D|E|$1E|1F]]|1G|$5|1B|1C|1D|E|$1E|1H]]|1I|$5|1B|1C|1D|E|$1E|1J]]]]

The <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf" rel="nofollow noreferrer">standard</a> says nothing about the size of <code>long int</code>, so it is dependent on the environment which you are using. 

To get the size of <code>long int</code> on your environment you can use the <code>sizeof</code> operator and get the size of <code>long int</code>. Something like

<pre><code>sizeof(long int)
</code></pre>

<blockquote>
 C standard only requires the following points about the sizes of types
 
 <ul>
 <li>int >= 16 bits,</li>
 <li>long >= 32 bits,</li>
 <li>long long (since C99) >= 64 bits</li>
 <li>sizeof(char) &lt;= sizeof(short) &lt;= sizeof(int) &lt;= sizeof(long) &lt;= sizeof(long long)</li>
 <li>sizeof(char) == 1</li>
 <li>CHAR_BIT >= 8</li>
 </ul>
 
 The remaining are implementations defined, so it's not surprised if
 one encountered some systems where int has 18/24/36/60 bits, one's 
 complement signed form, sizeof(char) == sizeof(short) == sizeof(int)
 == sizeof(long) == 4, 48-bit long or 9-bit char like Exotic architectures the standards committees care about and List of
 platforms supported by the C standard
 
 The point about long int above is completely wrong. Most Linux/Unix 
 implementations define long as a 64-bit type but it's only 32 bits in 
 Windows because they use different data models (have a look at the
 table here <a href="https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models" rel="nofollow noreferrer">64-bit computing</a>), and this is regardless of 32 or 64-bit
 OS version.
</blockquote>

<a href="https://www.quora.com/Why-do-long-int-and-char*-take-up-different-amount-of-space-in-32-bit-and-64-bit-machines" rel="nofollow noreferrer">Source</a>

blocks|key|2714805|text|来自Usrmisc的博客：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2714806|标准把它完全留给编译器，这也意味着同一个编译器可以使它依赖于选项和目标体系结构。|blockquote|2714807|所以你不能。|style|BOLD|2714808|顺便说一句，即使是long+int也可能和long一样。|CODE|2714809|entityMap|0|LINK|mutability|MUTABLE|url|https://usrmisc.wordpress.com/2012/12/27/integer-sizes-in-c-on-32-bit-and-64-bit-linux/^0|2|B|0|0|0|0|5|0|9|8|L|4|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|F|7|Z|8|@]|9|@]|C|$]]|$1|G|3|H|5|6|7|10|8|@$A|11|B|12|I|J]]|9|@]|C|$]]|$1|K|3|L|5|6|7|13|8|@$A|14|B|15|I|M]|$A|16|B|17|I|M]]|9|@]|C|$]]|$1|N|3|-4|5|6|7|18|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

From <a href="https://usrmisc.wordpress.com/2012/12/27/integer-sizes-in-c-on-32-bit-and-64-bit-linux/" rel="nofollow noreferrer">Usrmisc's Blog:</a>
<blockquote>
The standard leaves it completely up to the compiler, which also means the same compiler can make it depend on options and target architecture.
</blockquote>
So you can't.
Incidentally even <code>long int</code> could be the same as <code>long</code>.

blocks|key|372030|text|简短回答:不！您不能对long+int的大小作出固定的假设。因为，标准(C标准或POSIX)没有记录long+int的大小(正如反复强调的那样)。为了给您的信念提供一个反例，64位系统中的大多数都有大小为64的long！要最大限度地提高可移植性，请适当使用sizeof。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|372031|使用sizeof(long+int)检查大小，它返回long的大小(以字节为单位)。该值与系统或环境有关；也就是说，编译器根据硬件和操作系统确定大小。|372032|entityMap^0|B|8|1E|8|2X|4|3K|6|0|2|G|Q|4|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|I|$]]

Short answer: No! You cannot make fixed assumptions on the size of <code>long int</code>. Because, the standard (C standard or POSIX) does not document the size of <code>long int</code> (as repeatedly emphasized). Just to provide a counter example to your belief, most of the 64 bit systems have <code>long</code> of size 64! To maximize portability use <code>sizeof</code> appropriately. 

Use <code>sizeof(long int)</code> to check the size, it returns the size of <code>long</code> in bytes. The value is system or environment dependent; meaning, the compiler determines the size based on the hardware and OS.

blocks|key|2714867|text|不，您不能假设“长”数据类型的大小因编译器而异。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2714868|有关更多细节，请查看这文章。|offset|length|2714869|entityMap|0|LINK|mutability|MUTABLE|url|https://www.geeksforgeeks.org/need-long-data-type-c-cpp/^0|0|A|1|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

No, you can't assume that since the size of the “long” data type varies from compiler to compiler. 
Check out <a href="https://www.geeksforgeeks.org/need-long-data-type-c-cpp/" rel="nofollow noreferrer">this</a> article for more details.

Is it always true that <code>long int</code> (which as far as I understand is a synonym for <code>long</code>) is <code>4</code> bytes? 

Can I rely on that? If not, could it be true for a POSIX based OS?

Can I assume the size of long int is always 4 bytes?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

long int (据我所知，它是long的同义词)总是4字节吗？我能依赖这个吗？如果不是，基于POSIX的操作系统会是真的吗？

问我可以假设长int的大小总是4个字节吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我可以假设长int的大小总是4个字节吗？EN