【问题标题】:How do I work around the GCC "error: cast from ‘SourceLocation*’ to ‘int’ loses precision" error when compiling cmockery.c?在编译 cmockery.c 时,如何解决 GCC“错误:从‘SourceLocation*’转换为‘int’失去精度”错误?
【发布时间】:2011-06-02 23:25:29
【问题描述】:

我需要将使用 Cmockery 的单元测试添加到用作手工制作的 Makefile 的现有构建环境中。所以我需要弄清楚如何构建 cmockery.c(没有 automake)。

当我跑步时:

g++ -DHAVE_CONFIG_H -DPIC -I ../cmockery-0.1.2 -I /usr/include/malloc -c ../cmockery-0.1.2/cmockery.c -o obj/cmockery.o

我得到一长串这样的错误:

../cmockery-0.1.2/cmockery.c: In function ‘void initialize_source_location(SourceLocation*)’:
../cmockery-0.1.2/cmockery.c:248: error: cast from ‘SourceLocation*’ to ‘int’ loses precision

这里是 cmockery.c 的第 247:248 行:

static void initialize_source_location(SourceLocation * const location) {
    assert_true(location);

assert_true 在 cmockery.h 的第 154 行定义:

#define assert_true(c) _assert_true((int)(c), #c, __FILE__, __LINE__)

所以问题(如错误所示)是 GCC 不喜欢从“SourceLocation*”转换为“int”。

我可以使用./configuremake(在Linux 上,如果我首先使用export CFLAGS=-I/usr/include/malloc 则使用on Mac OS X)构建Cmockery,没有任何错误。当我运行make./configure 之后)时,我尝试查看编译 cmockery.c 的命令行:

 gcc -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Isrc/google -I/usr/include/malloc -MT libcmockery_la-cmockery.lo -MD -MP -MF .deps/libcmockery_la-cmockery.Tpo -c src/cmockery.c  -fno-common -DPIC -o .libs/libcmockery_la-cmockery.o

...但我没有看到任何可能解决此错误的选项。

在“error: cast from 'void*' to 'int' loses precision”中,我看到我可以将 cmockery.h 中的 (int) 更改为 (intptr_t)。我已经确认这是有效的。但既然我可以用./configuremake 构建Cmockery,那么必须有一种方法可以在不修改源代码的情况下构建它。

【问题讨论】:

  • 嗯,它让你知道指针(现在 64 个)比整数(可能是 32 个)大。我想知道双重转换或类似 (int)(((long long) x) & 0x00000000ffffffff) 之类的东西是否足以欺骗它。
  • 你试过用gcc代替g++吗?使用 g++ 偶尔会改变语言的一些内容。
  • 大卫,将演员更改为 (intptr_t) 有效,但我不应该修改 Cmockery 源代码。
  • thkala,使用 gcc 将错误更改为警告。谢谢!

标签: gcc casting compilation cmockery


【解决方案1】:

在我的系统上使用 gcc 而不是 g++ 会将该错误变成我系统上的警告(Mandriva Linux 2010.1 64 位)并允许编译完成:

.
.
.
../cmockery-0.1.2/cmockery.c:248: warning: cast from pointer to integer of different size
.
.
.

但是,我觉得有必要指出,当我在相对常见的平台(Linux 64 位/GCC,我假设其他平台)上看到一大堆警告时,我通常会保持警惕。使用 -m32 选项强制编译为 32 位目标文件不会产生任何警告,因此可以假定按原样使用的源代码可能不是 64 位干净的。无论您是否使用自动工具,都会发生这种情况。

我不知道有问题的项目,所以它可能很好,但无论如何都要谨慎使用......

编辑:

根据this 对 OP 对 cmockery 邮件列表的问题的回答,目前的版本不是 64 位干净的。似乎错误/警告的存在是有充分理由的......

【讨论】:

猜你喜欢
  • 2010-12-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-10-19
  • 2021-11-09
  • 2022-12-31
  • 2014-10-18
相关资源
最近更新 更多