完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
您好,我在用PIC18F开发警告时发现这个讨厌的警告:(751)在访问一个比特字段的数据时,在常量表达式中溢出算术。我已经阅读了许多关于这个运算出现的线索,而不是关于移位操作出现的事实。我的代码我有这样的类型定义:TyPulfEnUM {StasuSufLoWangZoLe= 0,StavasFraveOne,StavasFrave2 StutsSuffFrave3,StavasFrave4,StavasFrave5,……StutsFraseFix15,StasuSubLaMax,StasuSraveStand=65535 } MyType;MyType位字段;然后在BiFieldE上操作宏:Bifield 1=1 & lt;StutsFrave2;Bield&= ~(-lt;& lt;StasuSraveS5);以及这样。使用的是,枚举中的StasuSraveStRead=65535定义强制该类型为16位(否则定义为最大的数字为16,将创建默认的8位宽类型)。所有作品都没有任何问题。几乎是这样。如果我这样做:符号INT测试;//BITFEAR一个已签名的int,这就避免了关于隐式符号改变CasTest= BiField&a;(1 & lt;& lt;StassFlasf15)的另一个恼人警告;(751)常数表达式中的算术溢出,相等的=Bifield和(1和lt;& lt;15);/警告:(751)在常数表达式中出现了算术溢出,提到的警告出现了。我跟踪了一个事实,即将1移到最后一个MSB位意味着改变数字的符号。如果类型是无符号的,则所有的工作都是正确的:例如:无符号int位字段;UNS。In test;test =位字段和(1和lt;lt;15);/ /没有警告产生,所以解决方案将使用签名类型。不幸的是,我不能看到我使用一个明显创建签名类型的TyBuffEnEng.问题是:我们如何能够抵御这个和恼人的一个,即使对一元操作符(如“!”),它也会不断警告符号隐式抛出。当然,不使用比特15或浪费代码和内存用于32位宽的类型解决了警告,但我不想浪费宝贵的资源,因为它似乎是一个编译器问题(我在代码中使用许多位字段,以保持内存占用小,同时利用强大的位集/测试/清除)指令也能访问代码小。谢谢任何建议。我忘记了。如果有任何区别,我使用编译器XC8 V1.45
以上来自于百度翻译 以下为原文 Hello, I am finding this annoying warning while developing with PIC18F: warning: (751) arithmetic overflow in constant expression when accessing data like a bitfield. I have read many thread about this appearing for arithmetic operations but not about the fact that it appears for shifting operations. In my code I have this kind of type definition: typedef enummyType bitfield; Then I operate on the birfield with macros that do this: bitfield |= 1<and such. As the size of the type defined is dependent from the actual values used, STATUSFLAG_SIZE = 65535 definition in the enum forces the type to be 16bit (otherwise maximum number defined is 16 which will create a default 8 bit wide type). All works without any problem. Almost. If I do this: signed int test; // being bitfield a signed int this avoid the other annoying warning about implicit sign change castThe mentioned warning appears. I have tracked the reason to be the fact that shifting 1 to the last MSB bit means changing the sign of the number. Everything works correctly if the type is an unsigned one: For example: unsigned int bitfield; So the solution would be using a signed type. Unfortunately I can't seen I use a typedef enum that apparently creates signed types. The question is: how can we defend ourselves against this and the annoying one that constantly warn for sign implicit cast even for unary operator like '!')? Of course not using bit 15 or wasting code and memory for a 32bit wide type solves the warning, but I do not want to waste precious resources for what it appears to be a compiler issue (I use many bitfields in my code to keep memory footprint small while exploiting the powerful bit set/test/clear instructions that also keep accessing code small). Thanks for any suggestion CiccioB P.S: I forgot. I use compiler XC8 v1.45 if that make any difference |
|
相关推荐
11个回答
|
|
|
|
|
|
不,不幸的是,这行不通。这种类型依然存在。
以上来自于百度翻译 以下为原文 No, unfortunately that doesn't work. The type remains signed.mad: |
|
|
|
|
|
|
|
移位量的类型不影响表达式的类型。
以上来自于百度翻译 以下为原文 test = bitfield & (1U<<15); The type of the shift amount doesn't affect the type of the expression. |
|
|
|
|
|
|
|
是的,试试看。如果你移动了14,没有警告,如果你移动了15,数字符号就被改变了,如果BITFAULT在INT上签名,就会产生警告。如果它是一个无符号的INT,就不会产生警告。正确的解决方法是将目标位字段转换成一个无符号的类型,但是用于访问位场的公共宏。S在许多不同类型的大小上运行,所以Ad-hoc铸件不是最好的解决方案。
以上来自于百度翻译 以下为原文 Yes, it does. Try it. If you shift by 14 no warning, if you shift by 15 the number sign is changed and the warning is produced if bitfiled is signed int. If it is an unsigned int no warning is produced. The right solution is to cast the target bitfield to an unsigned type, but the common macros for accessing the bitfields operate on many different type sizes, so a ad hoc casting is not the best solution. test = (unsigned int)bitfield & (1U<<15); |
|
|
|
重要的是你正在转移的价值的类型,而不是你正在转移的价值的类型。如果15是签名的或未签名的,这没有区别,所以枚举的基础类型也没有区别。
以上来自于百度翻译 以下为原文 What matters is the type of the value you are shifting, not the type of the value you are shifting by. It makes no difference if the 15 is signed or unsigned, so it also makes no difference what the underlying type of your enum is. |
|
|
|
重要的是你正在转移的价值的类型,而不是你正在转移的价值的类型。如果15是已签名的或未签名的,则没有区别,因此枚举的基础类型也没有区别。然而,位场的类型只是尝试一下,看看会发生什么。
以上来自于百度翻译 以下为原文 What matters is the type of the value you are shifting, not the type of the value you are shifting by. It makes no difference if the 15 is signed or unsigned, so it also makes no difference what the underlying type of your enum is. Right, the type of the number to shift is not important. The type of the bitfield does, however. Just try: unsigned int ubitf = 0U; signed int ***itf = 0; unsigned test = 0U; test = ubitf & (1U<<15); test = ***itf & (1U<<15); and see what happens |
|
|
|
当然。C的规则规定,AND运算符的两个操作数都将转换为公共类型,并且不能表示未签名int中的符号int的所有值,反之亦然。
以上来自于百度翻译 以下为原文 Of course. The rules of C dictate that both operands of the AND operator will be converted to a common type, and you can't represent all values of a signed int in an unsigned int, or vice versa. |
|
|
|
重要的是你正在转移的价值的类型,而不是你正在转移的价值的类型。如果15是已签名的或未签名的,则没有区别,因此枚举的基础类型也没有区别。然而,位场的类型,只是尝试一下,看看发生了什么,看不到你的观点。当把一个位移到签名的int的符号位置时,为什么不期望这个错误呢?您已经执行了一个操作,它溢出了int并导致它变为负值。为什么你认为这是个问题?
以上来自于百度翻译 以下为原文 What matters is the type of the value you are shifting, not the type of the value you are shifting by. It makes no difference if the 15 is signed or unsigned, so it also makes no difference what the underlying type of your enum is. Right, the type of the number to shift is not important. The type of the bitfield does, however. Just try: unsigned int ubitf = 0U; signed int ***itf = 0; unsigned test = 0U; test = ubitf & (1U<<15); test = ***itf & (1U<<15); and see what happens I do not see your point. Why would you NOT expect this error when shifting a bit into the sign position of a signed int? You have performed an operation the has overflowed the int and resulted in it becoming negative. Why do you think this is an issue? |
|
|
|
在这里,您正在创建一个有符号和无符号的类型,因此编译器警告一个隐式转换并不奇怪。这不是可移植的,也不保证是16位(它可能更大)。如果您想要一个16位的无符号类型,我建议声明它是这样的。
以上来自于百度翻译 以下为原文 Here, you're ANDing a signed and unsigned type, so it's not surprising the compiler warns about an implicit conversion. This isn't portable or guaranteed to be 16 bit (it could be larger). If you want a 16-bit unsigned type, I would suggest declaring it as such. |
|
|
|
只有小组成员才能发言,加入小组>>
5161 浏览 9 评论
1999 浏览 8 评论
1928 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3171 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2226 浏览 5 评论
731浏览 1评论
613浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
503浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
629浏览 0评论
527浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-22 22:22 , Processed in 1.306019 second(s), Total 99, Slave 82 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号