C中的typedef uint32冲突

在my.c文件中包含两个外部头文件会导致unit32的typedef冲突，因为这两个文件中的类型定义不同（第一个文件中为

typedef unsigned long

，第二个文件中为

typedef unsigned int

）。该代码用于32位微控制器。 在不更改外部文件中的代码的情况下，解决此类问题的最佳方法是什么？我用谷歌做了很多研究，但我找不到解决办法。我找到了以下线程：。 我试过那种方法，但没用。因为我都不明白这个解决方案是如何工作的，所以我很可能在代码中犯了错误。有人能给我举一个如何实现它的例子吗？

---

谢谢

因为这两个定义都描述了32位的

无符号整数

（例如，通过调用它

uint32

），所以它应该表示4字节的

无符号整数

，无论它是以何种方式定义的。您应该在特定的编译器中检查

sizeof（int）

和

sizeof（long）

对于32位微控制器爱好者来说，以下可能是正确的：

sizeof（long）==sizeof（int）

假设两个

typedef

都定义了一个无符号的4字节

int

，在用法上没有实际区别

如果它们的大小不同，则其中一个typedef被错误地命名为

uint32

，应根据编译器中该类型的大小命名为

uint16

，或

uint64

但是，如果更改

typedef

名称以使其更准确，则必须找到使用typedef的任何其他代码，并根据所需的存储大小使其使用正确的typedef

因为它是一个微控制器的编译器，在你的上面可能没有包含这两个文件的软件堆栈，所以你可能没问题。例如，只有您编写的代码才重要，但如果有其他软件包含代码，请检查并相应更新

如果某些代码包含一个头，但不包含另一个头，则需要确保在包含的

.h

中定义它，但为了确保

uint32

类型只定义一次，您可以使用C预编译器添加一个“保护”，以防止出现多个包含（以及随后的编译时冲突错误）详情如下:

在一个.h文件中：

#ifndef _UINT32
typedef unsigned long uint32
#define _UINT32
#endif

另一方面：

#ifndef _UINT32
typedef unsigned int uint32
#define _UINT32
#endif

---

请包含一些代码。如果标题可以公开访问，那么查看一下会很有帮助。我会怀疑typedefs

unsigned long uint32\t

的代码。这可能适用于16位平台。@EOF 32位平台通常有

int

和

long

两个32位（ILP32）。@EOF:

无符号long

对于大多数32位平台也是32位。您可能正在考虑64位平台，其中通常为64位（例如Linux-x64）。已完成我的编辑。对不起，我的答案在第一篇文章之后有了很大的变化。谢谢你的回答，在不改变外部头文件的代码的情况下，有没有一个很好的解决方案？请。谢谢你对答案投赞成票。回答你的问题：问问你自己，这是一个供应商错误吗？你应该报告吗？（是的）。他们可能会在补丁或更新中修复它

uint32/uint32\u t

应在

types.h

或类似文件中定义，以避免此类问题。其他消费者是谁？在问题所在的地方一劳永逸地解决它是否更有意义？后续的供应商更新会破坏您的修复吗？它不是UNIX，那里有很多使用者&需要root访问。它是亲密的；只影响你。你的编译器。显而易见的解决办法。我会在源代码处修复它——问题已经解决。没有很好的解决方案的原因是它是一个基本的设计缺陷，很容易避免，并且应该由头文件的提供者和架构师来避免。这就是为什么所有这些类型都应该在一个带有包含保护的头文件中定义（以防止重新包含，无论有多少头文件包含它）。那就不是问题了。这才是真正的解决方案，而不是事后诸葛亮。只是适当的标题设计。这就是为什么我认为您或供应商应该修复它。我推荐的是一种简单、可靠、安全和理智的解决方法。