C 编译器标志忽略符号
我目前正在处理从第三方承包商购买的代码。一个结构体有一个 unsigned char 字段，而它们将该字段传递给的函数需要一个signed char。编译器不喜欢这样，因为它认为它们是不匹配的类型。然而，它显然是为该承包商编译的。一些谷歌搜索告诉我“char 对象是否可以保存负值是由实现定义的”。承包商的编译器是否可以基本上忽略有符号/无符号类型并将它们视为相同的？或者是否有一个编译器标志可以将它们视为相同的？
C 不是我最擅长的语言——只需看看我的用户页面上的标签——所以任何帮助将不胜感激。
I am currently dealing with code purchased from a third party contractor. One struct has an unsigned char field while the function that they are passing that field to requires a signed char. The compiler does not like this, as it considers them to be mismatched types. However, it apparently compiles for that contractor. Some Googling has told me that "[i]t is implementation-defined whether a char object can hold negative values". Could the contractor's compiler basically ignore the signed/unsigned type and treat them the same? Or is there a compiler flag that will treat them the same?
C is not my strongest language--just look at my tags on my user page--so any help would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实际上，
char、signed char和unsigned char是三种不同的类型。根据标准 (ISO/IEC 9899:1990)：（例如，在 C++ 中，如果您有 char 参数，您必须（或至少应该）编写具有 char 参数的三个变体的重写函数）
普通 char 可能会被编译器视为有符号或无符号，但标准说（也在 6.1 中） .2.5):
和
5.2.1 中提到的字符是 AZ、az、0-9、空格、制表符、换行符和以下 29 个图形字符：
回答
所有这些我解释为基本上意味着值小于 128 的 ascii 字符保证是积极的。因此，如果存储的值始终小于 128，那么它应该是安全的（从保值的角度来看），尽管不是很好的做法。
Actually
char,signed charandunsigned charare three different types. From the standard (ISO/IEC 9899:1990):(and in C++ for instance you have to (or at least should) write override functions with three variants of them if you have a char argument)
Plain char might be treated signed or unsigned by the compiler, but the standard says (also in 6.1.2.5):
and
The characters referred to in 5.2.1 are A-Z, a-z, 0-9, space, tab, newline and the following 29 graphic characters:
Answer
All of that I interpret to basically mean that ascii characters with value less than 128 are guarantied to be positive. So if the values stored always are less than 128 it should be safe (from a value preserving perspective), although not so good practice.
这是依赖于编译器的。例如，在 VC++ 中，如果该选项指示默认使用 unsigned char，则定义一个编译器选项和一个相应的 _CHAR_UNSIGNED 宏。
This is compiler-dependent. For example, in VC++ there's a compiler option and a corresponding _CHAR_UNSIGNED macro defined if that option instructs to use unsigned char by default.
我认为您正在谈论
signed char和unsigned char类型的字段，因此它们显然是错误的。如果其中之一只是char，它可能会在承包商使用的任何编译器中匹配（IIRC，它是实现定义的char是否是signed或unsigned），但不是你的。在这种情况下，您也许可以使用命令行选项或其他方式来更改您的选项。或者，承包商可能正在使用编译器或编译器选项，这允许他在忽略错误或警告的同时进行编译。你知道他有什么样的编译环境吗？
无论如何，这都不是好的 C。如果其中一种类型只是
char，那么它依赖于实现定义的行为，因此不可移植。如果不是，那就大错特错了。我会和承包商一起解决这个问题。I take it that you're talking about fields of type
signed charandunsigned char, so they're explicitly wrong. If one of them was simplychar, it might match in whatever compiler the contractor is using (IIRC, it's implementation-defined whethercharissignedorunsigned), but not in yours. In that case, you might be able to get by with a command-line option or something to change yours.Alternatively, the contractor might be using a compiler, or compiler options, that allow him to compile while ignoring errors or warnings. Do you know what sort of compilation environment he has?
In any case, this is not good C. If one of the types is just
char, it relies on implementation-defined behavior, and therefore isn't portable. If not, it's flat wrong. I'd take this up with the contractor.