如何解决 GCC“错误:来自“SourceLocation*”的转换?到“int”失去精度”编译cmockery.c时出错?

发布于 2024-10-10 07:25:25 字数 1916 浏览 0 评论 0原文

我需要使用 Cmockery 将单元测试添加到用作手工制作的现有构建环境中生成文件。所以我需要弄清楚如何构建 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

Here arelines 247:248 of cmockery.c:

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

assert_true is Define on line 154 of cmockery.h:

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

所以问题(作为错误状态)是 GCC 不喜欢从 'SourceLocation*' 到 'int' 的转换。

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

 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

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

在“错误:从 'void*' 到 'int' 的转换丢失精度”,我发现我可以将 cmockery.h 中的 (int) 更改为 (intptr_t)。我已经确认这是有效的。但由于我可以使用 ./configuremake 构建 Cmockery,因此必须有一种方法可以在不修改源代码的情况下构建它。

I need to add unit tests using Cmockery to an existing build environment that uses as hand-crafted Makefile. So I need to figure out how to build cmockery.c (without automake).

When I run:

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

I get a long list of errors like this:

../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

Here are lines 247:248 of cmockery.c:

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

assert_true is defined on line 154 of cmockery.h:

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

So the problem (as the error states) is GCC doesn't like the cast from ‘SourceLocation*’ to ‘int’.

I can build Cmockery using ./configure and make (on Linux, and on Mac OS X if I export CFLAGS=-I/usr/include/malloc first), without any errors. I've tried looking at the command-line that compiles cmockery.c when I run make (after ./configure):

 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

...but I don't see any options that might work around this error.

In "error: cast from 'void*' to 'int' loses precision", I see I could change (int) in cmockery.h to (intptr_t). And I've confirmed that works. But since I can build Cmockery with ./configure and make, there must be a way to get it to build without modifying the source.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

白鸥掠海 2024-10-17 07:25:25

在我的系统上使用 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 位干净的。似乎错误/警告的存在是有充分理由的......

Using gcc instead of g++ on my system turns that error into a warning on my system (Mandriva Linux 2010.1 64-bit) and allows the compilation to complete:

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

I feel the need to point out, however, that I am generally wary when I see a whole horde of warnings on what is a relatively common platform (Linux 64-bit/GCC and I would presume others). Using the -m32 option to force compilation to a 32-bit object file does not produce any warnings, so one could presume that the source code used as-is is may not be 64-bit clean. This happens whether you use the autotools or not.

I don't know the project in question, so it might very well be OK, but in any case use with caution...

EDIT:

According to this answer to the OP's question to the cmockery mailing list, the current release is not 64-bit clean at this time. It seems that the errors/warnings were there for a good reason...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文