15 
#include <limits.h>
#include <stdio.h>
int main() {
    long ival = 0;
    printf("ival: %li, min: %i, max: %i, too big: %i, too small: %i\n",
           ival, INT_MIN, INT_MAX, ival > INT_MAX, ival < INT_MIN);
}

这给出了输出：

ival: 0, min: -2147483648, max: 2147483647, too big: 0, too small: 1

这怎么可能？

（实际上，我在 CPython 2.7.3 中遇到了这个问题/错误getargs.c：convertsimple。如果您在 中查找代码，case 'i'则检查ival < INT_MIN对我来说始终是正确的。另请参阅测试用例源和进一步的参考资料。）

好吧，我现在测试了几个不同的编译器。为 x86 编译的 GCC/Clang 都返回预期值（太小：0）。为 armv7 编译时，意外输出来自 Xcode 工具链中的 Clang。

如果你想重现：

这是确切的编译命令：/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk test-int.c

这是 Xcode 4.3.2。

我将结果复制a.out到我的 iPhone 并执行它。

如果有人对此生成的汇编代码感兴趣：

    .section    __TEXT,__text,regular,pure_instructions
    .section    __TEXT,__textcoal_nt,coalesced,pure_instructions
    .section    __TEXT,__const_coal,coalesced
    .section    __TEXT,__picsymbolstub4,symbol_stubs,none,16
    .section    __TEXT,__StaticInit,regular,pure_instructions
    .syntax unified
    .section    __TEXT,__text,regular,pure_instructions
    .globl  _main
    .align  2
    .code   16
    .thumb_func _main
_main:
    push    {r7, lr}
    mov r7, sp
    sub sp, #20
    movw    r0, #65535
    movt    r0, #32767
    movs    r1, #0
    movt    r1, #0
    str r1, [sp, #16]
    str r1, [sp, #12]
    ldr r1, [sp, #12]
    ldr r2, [sp, #12]
    cmp r2, r0
    movw    r0, #0
    it  gt
    movgt   r0, #1
    and r0, r0, #1
    ldr r2, [sp, #12]
    cmn.w   r2, #-2147483648
    movw    r2, #0
    it  lt
    movlt   r2, #1
    and r2, r2, #1
    mov r3, sp
    str r2, [r3, #4]
    str r0, [r3]
    mov.w   r2, #-2147483648
    mvn r3, #-2147483648
    movw    r0, :lower16:(L_.str-(LPC0_0+4))
    movt    r0, :upper16:(L_.str-(LPC0_0+4))
LPC0_0:
    add r0, pc
    blx _printf
    ldr r1, [sp, #16]
    str r0, [sp, #8]
    mov r0, r1
    add sp, #20
    pop {r7, pc}

    .section    __TEXT,__cstring,cstring_literals
L_.str:
    .asciz   "ival: %li, min: %i, max: %i, too big: %i, too small: %i\n"


.subsections_via_symbols
4

2 回答 2

5

这是一个错误。在 C 标准中too small，除了 0 之外没有任何空间。这是它的工作原理：

  1. 由于INT_MIN是int，它long在“通常的算术转换”期间被转换为。发生这种情况是因为long排名高于int（并且都是有符号类型）。没有提升发生，因为所有操作数都至少有int等级。不调用未定义或实现指定的行为。

  2. 在转换期间，INT_MIN保留 的值。由于它正在从 转换int为long，并且保证long至少具有 的范围，因此在转换过程中必须保留int的值。INT_MIN不调用未定义或实现指定的行为。不允许进行模块化转换，仅适用于无符号类型。

  3. 比较的结果应该是0。

标志扩展或其他此类事情没有回旋余地。此外，由于调用printf是正确的，所以那里没有问题。

如果您可以在另一个系统上重现它，或者将它发送给可以重现它的其他人，您应该直接将错误报告给您的工具链供应商。

尝试重现错误：我无法重现以下任何组合的行为，所有组合都开启和关闭优化：

  • GCC 4.0，PPC + PPC64
  • GCC 4.2，PPC + PPC64
  • GCC 4.3，x64
  • GCC 4.4，x64
  • 铿锵 3.0，x64
于 2012-06-20T23:22:36.790 回答
1

这个打印什么？

#include <limits.h>

printf("%016ld\n", LONG_MAX);

long l_int_min = (long)INT_MIN;
printf("%016lx\n", l_int_min);

我想知道是否在没有符号扩展的情况下被INT_MIN强制执行。long这将使 0 小于结果值。

编辑：好的，第一个的结果printf()是0000002147483647，这意味着long在那个平台上是 32 位的，就像int. 因此，将 anint转换为 along实际上不应该改变任何东西。

我试图保留“这是一个编译器错误”作为最后的手段，但这对我来说看起来像是一个编译器错误。

于 2012-06-20T23:10:11.050 回答