ç字面后缀U，UL问题 [英] C literal suffix U, UL problems
问题描述
可能有人给我ANSI C解释会发生什么，如果我会忘记为常数（文字）后缀（后缀）？
Could someone explain to me what can happen if I'll forget suffix(postfix) for constants(literals) in ANSI C?
例如我看到了移位操作，定义：
For example I saw for bit shift operations such defines:
#define AAR_INTENSET_NOTRESOLVED_Pos (2UL) /*!< Position of NOTRESOLVED field. */
#define AAR_INTENSET_NOTRESOLVED_Msk (0x1UL << AAR_INTENSET_NOTRESOLVED_Pos) /*!< Bit mask of NOTRESOLVED field. */
#define AAR_INTENSET_NOTRESOLVED_Disabled (0UL) /*!< Interrupt disabled. */
#define AAR_INTENSET_NOTRESOLVED_Enabled (1UL) /*!< Interrupt enabled. */
#define AAR_INTENSET_NOTRESOLVED_Set (1UL) /*!< Enable interrupt on write. */
它在32位架构中使用。但也有可能被移植到16位或8位。
如果不使用后缀UL和它应该是我会用这些宏位移运算会发生什么？
It's used in 32bit architecture. But it could be ported to 16bit or 8bit. What can happen if postfix UL is not used and I'll use these macros for bit shift operations as it is supposed?
我只是假设，例如在8位架构可以（1 <<;小于30）导致溢出
I just assume that e.g. in 8-bit architecture can (1<<30) leads to overflow.
修改：我找到了很好的链接：http://dystopian$c$c.blogspot.cz/2012/08/constant-suffixes-and-$p$pfixes-in-ansi-c.html
EDIT: I have found nice link: http://dystopiancode.blogspot.cz/2012/08/constant-suffixes-and-prefixes-in-ansi-c.html
不过是可以安全使用后缀如果code被认为在不同的架构来进行移植？
But is it safe to use suffixes if the code is supposed to be ported on various architectures?
例如，如果后缀ü重新presents unisgned INT所以8位架构它通常是16位，但对于32位是32位的变量，因此0xFFFFAAAAU是确定32位编译器而不是8位编译器，对吧？
For instance if suffix U represents unisgned int so for 8bit architecture it's usually 16bit but for 32bit it's 32bit variable, so 0xFFFFAAAAU is ok for 32bit compiler but not for 8bit compiler, right?
推荐答案
一个十进制数一样-1,1,2,12345678等不带任何后缀会得到它适合最小的类型，从 INT ，长，长长。
A decimal number like -1,1,2,12345678, etc. without any suffix will get the smallest type it will fit, starting with int, long, long long.
这是八进制或十六进制数字如0，0123，为0x123，0x123的不带任何后缀会得到它适合，从 INT 最小的类型，无符号，长，无符号长，长长，无符号长长。
An octal or hex number like 0, 0123, 0x123, 0X123 without any suffix will get the smallest type it will fit, starting with int, unsigned, long, unsigned long, long long, unsigned long long.
下面是一个潜在的问题应该 AAR_INTENSET_NOTRESOLVED_Pos 31，超出注：无符号长必须在至少的32位。这将导致0 **如果无符号长为32位，但不为零，如果更长的时间。
The following is a potential problem should AAR_INTENSET_NOTRESOLVED_Pos exceed 31. Note: unsigned long must be at least 32 bits. It would result in 0 ** if unsigned long was 32 bits, but non-zero if longer.
(0x1UL << AAR_INTENSET_NOTRESOLVED_Pos)
下面是一个类似的潜在问题，应 AAR_INTENSET_NOTRESOLVED_Pos 15，超过为0x1 是无符号，它只能是至少16位。此外，如果无符号/ INT 为16位，最低，为0x1 将 INT 。因此，没有明确使用 U ，为0x1 可能是一个问题，如果 AAR_INTENSET_NOTRESOLVED_Pos == 15 。 [@马特麦克纳布]
The following is a similar potential problem should AAR_INTENSET_NOTRESOLVED_Pos exceed 15. 0x1 is an unsigned, which must only be at least 16 bits. Also if unsigned/int is 16 bits, the minimum, 0x1 will be int. So without explicitly using U, 0x1 could be a problem if AAR_INTENSET_NOTRESOLVED_Pos == 15. [@Matt McNabb]
(0x1 << AAR_INTENSET_NOTRESOLVED_Pos)
按位移位运算符结果
整数优惠在每个操作数的执行。该类型的结果是，促进了左操作数。如果右操作数的值是负的，或大于或等于所述推动左操作数的宽度，所述行为是不确定的。 C11dr§6.5.73
Bitwise shift operators
"The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." C11dr §6.5.7 3
机器宽度不是关键问题。一个8位或16bit的机器可以使用16，32，等位大小 INT 。同样，16位是一个兼容的C编译器的最小尺寸。
Machine width is not the key issue. An 8bit or 16bit machine could use 16, 32, etc. bit size int. Again, 16 bit is the minimum size for a compliant C compiler.
**
我应该说：这（移动超过31位）将导致不确定的行为， UB ，如果无符号长为32位。
**
I should have said " It (shifting more than 31 bits) would result in Undefined behavior, UB, if unsigned long was 32 bits."
这篇关于ç字面后缀U，UL问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
