sybdb.h 导致“声明说明符中有两个或多个数据类型”
我正在编译一个包含 sybdb.h 的 C 程序,并且在下面的 typedef 行中收到错误“声明说明符中的两个或多个数据类型”(并且 sybdb.h 是一个标准文件,不是我的文件)。
#if !defined(_WINDEF_) && !defined(_WINDEF_H) && !defined(DOS32X)
typedef int BOOL;
#endif
似乎与我包含的另一个库存在某种冲突,但不知道错误意味着什么或如何修复它。帮助?
I'm compiling a C program which includes sybdb.h and I get the error "two or more data types in declaration specifiers" at the typedef line below (and sybdb.h is a standard file, not one of mine).
#if !defined(_WINDEF_) && !defined(_WINDEF_H) && !defined(DOS32X)
typedef int BOOL;
#endif
It appears that there is some kind of a conflict with another library I am including, but have no idea what the error means or how to fix it. Help?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
很可能另一个标头(或者你的C本身的实现)做了类似的事情:
这样你的编译器就会看到:
通过实验,当我编译代码时:
它工作正常,但是,当我改变时到 #define BOOL unsigned char 的第一行,我得到了与您看到的完全相同的消息:
要确认这一点,您可以仅编译预处理器阶段,以查看该代码对于编译器来说到底是什么样子阶段。
这取决于编译器,当然,
gcc -E
是您将用于gcc
的选项。修复它是另一回事。您可能必须将其中一种别名类型更改为
BOOL1
或类似的极其丑陋的东西。这可能是一个更大的变化,因为我想它会被大量使用。您也许可以简单地确保两个子系统使用相同的
BOOL
定义,但仍然需要进行大量分析来确认这不会有不良副作用。要测试(甚至可能实现)此修复,您可以将
#if
语句更改为类似以下内容:然后使用
gcc -DSKIP_BOOL_DEF
(或等效项)将代码编译为确保typedef
未完成。然后它将使用您的(希望兼容的)系统定义。Most likely another header (or your implementation of C itself) has done something like:
so that your compiler is seeing:
By way of experiment, when I compile the code:
it works fine but, when I change that first line to
#define BOOL unsigned char
, I get the exact same message you see:To confirm this, you can compile only the pre-processor phase to see what that code really looks like to the compiler phase.
This depends on the compiler, of course,
gcc -E
is the option you would use forgcc
.Fixing it is another matter. You may well have to change one of the alias types to
BOOL1
or something incredibly ugly like that. That's likely to be a larger change since I imagine it would be used quite a bit.You may be able to get away with simply ensuring both subsystems use the same definition of
BOOL
but it will still take quite a bit of analysis to confirm that this won't have adverse side effects.To test (and even possibly implement) this fix, you can change the
#if
statement to something like:and then compile your code with
gcc -DSKIP_BOOL_DEF
(or equivalent) to ensure thetypedef
isn't done. It would then use your (hopefully compatible) system definition.