带有无符号字符的隐式类型转换

可以降低警告级别。XC8的最新版本提高了默认警告级别。一致认为这是恼人的，但是标准的C整数提升是原因。你可以让它不那么令人讨厌，因为包含& lt；Stdit.h & gt；然后，你可以使用标准类型的快捷方式，比如“uut88t”，它比“unChar char”稍微有点侵入。



      以下为原文

    You can reduce the warning level. Recent versions of XC8 upped the default warning level. Agreed that it is annoying, but standard C integer promotions are the cause.
 
You can make it a little less unpleasant by #include - then you can use the standard type shortcuts like "uint8_t" which is a little less intrusive than "unsigned char".

欢迎来到“C傻瓜”俱乐部（只是戏弄）。C中的大多数算术运算都有一个整数结果（隐式定义）。因此。使用STNDIT.H很少有助于减轻这种影响。但是，由于变量的大小更容易识别，这使得代码更可读。



      以下为原文

    Welcome to the club of "C dummies" (just teasing).
 
Most arithmetic operations in C have an integer result (implicitly defined). THUS . . .
And the use of stdint.h serves little to mitigate this effect. But it makes the code more readable as the size of the variables is easier to discern.

是的，我知道“C”中的默认类型的int。更多的是困扰我的警告。我刚刚从MikroC移到XC8，其中我一直使用8位数据，没有任何隐式转换警告。我不愿意降低警告水平，因为我可能会错过一些潜在的吼叫，所以我一定会开始使用UTI88T来保持整洁。



      以下为原文

    Yes, I know about the default type of int in 'C'. It's more the plethora of warnings that was bothering me. I've just moved over to XC8 from MikroC, with which I used 8 bit data all the time without any kind of implicit conversion warning. I'm reluctant to reduce the warning level though because I could miss some potential howlers, so I'll definitely start using uint8_t to keep things tidy.

XC8&公司最近才成熟起来——包括多种类型的冲突警告。虽然这需要大量明确的类型转换来消除大部分（并非全部）的警告，但我认为类型转换是程序员成熟的标志：显示S/He知道O。不冲突的ANSI标准仍然允许各种关于警告的实现。并不是每一个编译器生产商都为ANSI标记而努力。（加上：像我这样的老狗仍然喜欢前ANSI K & R”标准。



      以下为原文

    It's only recently that XC8 & Co. matured significantly - including a multitude of type conflict warnings.
Although this requires a lot of explicit type casting to get rid of most (not all) of the warnings, I consider type casts as some sign of maturity of the programmer: showing s/he is aware of the conflicts.
 
The unfamous ANSI standard still allows for a variety of implementations regarding the warnings. And not every compiler producer even strives for the ANSI labeling.
(Plus: some old dogs like me still love the pre-ANSI K&R "standard".)

公平点，但我个人认为对于完全由同类型数据组成的操作的警告有点过分。如果你选择忽略它们，它可能会在更大的风险中忽略更严重的问题，无论是在杂乱的源代码中还是在大量的警告中。



      以下为原文

    Fair point, but personally I think a warning for an operation consisting entirely of identically typed data is a little excessive. Perhaps it runs a greater risk of overlooking far more serious issues either in the cluttered source code or in the reams of warnings if you choose to ignore them.

UCHAR + UCHAR可以很容易地超过UCHAR范围（130 + 130和gt；255），因此隐式的结果不是UCHAR。以类似的方式应用于其他操作。在某些应用程序中，溢出是一个严重的问题。（甚至从一些溢出的SIL应用程序中学习一次。）如果您不喜欢这些警告，则可以“解除”编译器。虽然我建议拥抱他们



      以下为原文

   
NO.
uchar + uchar can easily exceed the uchar range (130+130 > 255).
Thus the implicit type of the result is not uchar. Applies to other operations in a similar way.
And overflow is a serious issue in some applications.
(Even learned once from some overflow compromising SIL applications.)
 
If you don't like these warnings, you may "disarm" the compiler. Although I'd suggest to embrace them

哈哈。。。男孩是我的脸红！！！！我想我需要重返学校——今天我把我的注意力放在五月的事情上，所以不要直截了当地思考。



      以下为原文

    ha ha ... boy is my face red!!!   I think I need to go back to school - I've got my mind on may things today, so not thinking straight.

不时地回忆起最基本的东西。（希望你的脸是红色的）。



      以下为原文

    From time to time it is good to recall the very basics.
(Hope your face was red from ROFL )

OTHH，UIT1616T+UIT1616T也可以很容易超过UTI1616T范围。我也认为这个警告是过分的和令人讨厌的。编辑：我的观点是，这不会引起任何警告，所以这也不应该。编译器可以变得更智能。；）



      以下为原文

   
OTOH, uint16_t + uint16_t could also easily exceed the uint16_t range.  I also think this warning is excessive and annoying. ;)
 
Edit: My point is that this
uint16_t a, b, c;
c = a + b;

throws no warning, so this
uint8_t a, b, c;
c = a + b;

should not either.  The compiler can be made smarter. ;)
 
 

HTTP://www. McCHIP.COM/FUMMS/FUNDSPE/1021717



      以下为原文

    http://www.microchip.com/forums/FindPost/1021717

是啊，噪音太大了。编译器可以变得更智能。；）



      以下为原文

   
Yeah, too much noise.  The compiler can be made smarter. ;)

我保持警告水平设置为- 9！并获得很少的噪音。也许是一个不同的范例：不是“涂抹”源代码，而是精确地表达要做的事情。添加一些其他技术会产生快速、紧凑的代码，即使是在自由模式下。YEP.IIrC，K＆P；R指定了另一种解决这个问题的方法：进入下一个更大的数据。类型（可用性）。但是，如上所述的“警告副作用”的ANSI方法是编译器在瞄准合理的低错误计数软件时普遍接受的行为。（虽然我刚刚发现，枚举上的类型检查低于XC8 1.45的标准-当前版本！！！！幸运的是，我把这个项目设置为一些DoXEGEN测试项目：DoxEngor解析器抱怨将枚举值从一个枚举分配给另一个枚举类型的变量。我真的期待XC8来检查这个-我没有预料到这些天还有其他的“残酷”——例如MISRA警告抑制代码需要抑制静态代码分析警告：在软件的较低级别，你可以轻易地从一行源获得3条警告。代码。除了抑制警告本身之外，绝对没有办法消除这些警告。



      以下为原文

    I keep the warning level set to -9 ! And get very little noise.
 
Maybe a different paradigm: not "smearing" source code but precisely expressing what's to be done.
Adding some other techniques results in fast, compact code even in free mode.
 

Yep.
IIRC, K&R specified another approach on this problem: stepping up to the next-larger data type (availability provided).
But the ANSI approach with its "warnings side-effects" as described above is the generally-accepted behavior for a compiler when targeting reasonable, low-error count software. (Although I just recently found out that type checking on enums is way below standard for XC8 1.45 - the current version!!!
Fortunately I had the project set up as some doxygen test project: the doxygen parser complained about assigning enum values from one enum to a variable of another enum type. I really had expected XC8 to check for this - - - failed my expectations
 
There are other "cruelties" these days - e.g. the MISRA warning suppression codes required to suppress static code analysis warnings: in the lower levels of a software you can easily get 3 warnings from a single line of source code. And there is absolutely no way to get rid of these warnings other than suppressing the warning itself.