Clang,这些类型如何冲突?
试图用clang(在Windows上)编译Python解释器,我得到了(经过一些改进):
c:\Python-3.10.4\Python\pytime.c:603:5: error: conflicting types for '_PyTime_AsTimeval'
int _PyTime_AsTimeval(_PyTime_t t, struct timeval *tv, _PyTime_round_t round)
^
C:\Python-3.10.4\Include/cpython/pytime.h:126:5: note: previous declaration is here
int _PyTime_AsTimeval(_PyTime_t t, struct timeval *tv, _PyTime_round_t round);
^
嗯...这些看起来对我来说并不矛盾!我想念什么? Python代码在这些声明中是否有不寻常的事情?有没有办法让clang提供有关其所见冲突的更多信息? (Microsoft编译器无需投诉就接受了此代码。)
Trying to compile the Python interpreter with clang (on Windows), I'm getting (after some refinement):
c:\Python-3.10.4\Python\pytime.c:603:5: error: conflicting types for '_PyTime_AsTimeval'
int _PyTime_AsTimeval(_PyTime_t t, struct timeval *tv, _PyTime_round_t round)
^
C:\Python-3.10.4\Include/cpython/pytime.h:126:5: note: previous declaration is here
int _PyTime_AsTimeval(_PyTime_t t, struct timeval *tv, _PyTime_round_t round);
^
Um... those don't look conflicting to me! What am I missing? Does the Python code do something unusual with these declarations? Is there a way to get clang to give more information about the conflict it sees? (The Microsoft compiler accepted this code with no complaint.)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
找到了!问题在于
struct TimeVal
在读取功能声明时尚未声明。 Microsoft C认为“结构的全局声明将即将到来”; Clang将其视为“暂时声明,然后将其丢弃,以使函数原型与以后的定义不相容”。并且可以通过在函数原型之前插入此内容来对其进行修补:
我不知道哪种行为是否与标准的措辞更一致,但已将其报告为错误无论如何,以与微软编译器相同的方式行为的理论将是更有用的行为。
Found it! The problem is that
struct timeval
was not yet declared by the time the function declarations were read. Microsoft C takes that as meaning 'global declaration of the struct will be forthcoming'; clang takes it as 'make a temporary declaration, then discard it, so that the function prototype is incompatible with later definition'.And can be patched in
pytime.h
by inserting this before the function prototypes:I don't know which if either behavior is more consistent with the wording of the standard, but have reported it as a bug in clang anyway, on the theory that behaving the same way as the Microsoft compiler would be the more useful behavior.