1

此代码在 xlC 8.0（在 AIX 5.3 上）中编译时会产生错误的结果。它应该打印12345，而是打印804399880。删除const前面的result使代码正常工作。

错误在哪里？

#include <stdio.h>
#include <stdlib.h>
#include <string>

long int foo(std::string input)
{
        return strtol(input.c_str(), NULL, 0);
}

void bar()
{
        const long int result = foo("12345");
        printf("%u\n", result);
}

int
main()
{
        bar();
        return 0;
}

编译命令：

/usr/vacpp/bin/xlC example.cpp -g

编辑：将上面的 printf 格式字符串更改为 "%ld\n" 没有帮助。编辑 2：使用的 AIX 版本是 5.3，而不是 6.1。

4

5 回答 5

3

xlC 10.0 工作正常，似乎是编译器错误

于 2010-04-15T13:00:33.583 回答
2

这被标记为 c++，那么当您使用 cout 而不是 printf 时会发生什么？

看起来问题是你告诉 printf 打印一个 unsigned int 然后发送一个有符号的 long int 来实际打印。很可能内存布局不同， printf 无法理解您实际想要做什么。

于 2010-04-15T13:39:03.397 回答
1

这将是一个猜测为什么 const 很重要，但可以做出合理的假设。

具有块范围的变量，例如result可以分配到寄存器或放入堆栈。影响寄存器是否使用的因素有很多。const在这种情况下，这很可能很重要。最后，编译器有权使用它认为最有效的东西。

类似地，函数的参数可以在寄存器或堆栈中传递。由于函数通常是单独编译的，它们的接口（即声明）决定了哪个参数去哪里。printf(...) 是一种特殊情况，因为它可以使用不同类型的参数调用。因此，哪些数据最终会发生变化，您需要告诉 printf(...) 会发生什么。

现在，当将变量传递给函数时，编译器通常必须复制它。从一个寄存器到堆栈，一个寄存器到另一个，等等，可能有很多变化。正如我所指出的，源位置可能会有所不同，具体取决于const.

现在，碰巧您将错误的格式说明符传递给printf(...)，%u而不是%ld. 这可能会导致 printf(...) 在错误的位置查找数据 - 可能在寄存器而不是堆栈中，或者相反。这样的行动会导致相当惊人的结果。printf(...)例如，可能会偶然发现您的 uncopiedresult或某些寄存器中的随机旧值。似乎在非 const 情况下它碰巧找到了正确的值（即使它可能在错误的地方找到它），而在 const 情况下printf(...)只是找到垃圾。

于 2010-04-15T13:46:09.127 回答
0

可能不相关，但要小心： printf 的 %u 说明符表示一个无符号整数，但您传递的是一个有符号整数。

于 2010-04-15T13:04:41.087 回答
0

g++ 处理得很好，没有提到警告。它确实抱怨 printf。您应该将 %lu 用于 long int。或者甚至更好，使用 %ld 或强制转换为 (unsigned long int)。

于 2010-04-15T13:07:10.103 回答