• AVR Freaks

Hot!Another implicit signed to unsigned conversion warning

Page: < 12 Showing page 2 of 2
Author
1and0
Access is Denied
  • Total Posts : 9631
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Another implicit signed to unsigned conversion warning 2019/07/15 11:04:38 (permalink)
+1 (1)
LdB_ECM
It's hard to know what to do with it because it's wrong, I have stated why (in spite of 1and0 comment).
It doesn't warn with XC16, VS2017, VS2019, Keil DS5 or GCC 6,7 or 8 with wall on which didn't surprise me.
The result is fully predictable and there is no chance of any error from the optimization so it is allowed to ignore the promotion.

I understand your "why" and my comment is based on my own limited understanding of the C Standard. I am no C Standard expert; for that, we'll have to wait for Jeff (mad_c) or jtemples to chime in.
 

So personally I would just hack over it because to me it is junk but if you want to be anal then hit the C standards and see what is supposed to happen. The fact the all the other compilers ignore it tells me I am more likely right than wrong but I am not wasting time on it because at the end of the day it is perfectly safe.

I agreed with you this is "junk" but then there is the Standard. Let's see what Jeff has to say.
 
#21
mad_c
Super Member
  • Total Posts : 1193
  • Reward points : 0
  • Joined: 2010/12/12 17:48:27
  • Location: Brisbane, Australia
  • Status: offline
Re: Another implicit signed to unsigned conversion warning 2019/07/15 14:21:40 (permalink)
+3 (3)
1and0
I understand your "why" and my comment is based on my own limited understanding of the C Standard. I am no C Standard expert; for that, we'll have to wait for Jeff (mad_c) or jtemples to chime in.

 
Is that the Bat Signal I see?
 
Post #2 has it right. The result of the ? : operator will be signed int. That is then assigned to an unsigned char and the compiler is issuing a warning. I also agree that in that very instance, the warning is not helpful, but I note that this only occurs for the old P1 parser (used by C90 code) and that Clang (used for C99 programs) is silent about the whole thing. Casting the result of the ? : operator silenced the warning in my test code, so that might be the best work around.
 
Jeff.
 
#22
1and0
Access is Denied
  • Total Posts : 9631
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Another implicit signed to unsigned conversion warning 2019/07/15 14:44:36 (permalink)
0
mad_c
Casting the result of the ? : operator silenced the warning in my test code, so that might be the best work around.

I'll take that as the best work around as well for the second topic in this thread starting with post #9.
 
post edited by 1and0 - 2019/07/15 16:00:32
#23
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 11287
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: Another implicit signed to unsigned conversion warning 2019/07/15 14:45:32 (permalink)
+2 (2)
Casting the result of the ? : operator silenced the warning in my test code, so that might be the best work around

 
And of course including a comment as to why the cast is there.
#24
LdB_ECM
Senior Member
  • Total Posts : 144
  • Reward points : 0
  • Joined: 2019/04/16 22:01:25
  • Location: 0
  • Status: offline
Re: Another implicit signed to unsigned conversion warning 2019/07/15 17:07:48 (permalink)
0
Explain the second case it throws a warning at apparently .... no ? in that
const uint8_t kCmdMask = 0x80;
uint8_t cmdByte;
uint8_t mSerialCommand;
....
 mSerialCommand = cmdByte & kCmdMask;

post edited by LdB_ECM - 2019/07/15 17:09:32
#25
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 11287
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: Another implicit signed to unsigned conversion warning 2019/07/15 17:56:43 (permalink)
+1 (1)
Explain the second case it throws a warning at apparently .... no ? in that

 
That was explained in post #13.  The & operator promotes its operands to "int" in this case.
#26
1and0
Access is Denied
  • Total Posts : 9631
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Another implicit signed to unsigned conversion warning 2019/07/16 07:49:24 (permalink)
+2 (2)
LdB_ECM
Explain the second case it throws a warning at apparently .... no ? in that

Repeating my Post #13 in more details:
  1. The & operator promotes its two operands to signed int.
  2. The & operation is performed on the two signed int with a result of signed int.
  3. The assignment causes the right operand (signed int) to be converted to the type of the left operand (unsigned char).
  4. The compiler issues a warning.
The conversion rules are specified in the language standard. Compliant compilers follow those rules, regardless "the result is fully predictable and there is no chance of any error" or "it is junk" to you and me.
#27
mlp
boots too small
  • Total Posts : 794
  • Reward points : 0
  • Joined: 2012/09/10 15:12:07
  • Location: previously Microchip XC8 team
  • Status: offline
Re: Another implicit signed to unsigned conversion warning 2019/07/16 20:00:48 (permalink)
0
(getting further off-topic)
LdB_ECM
GCC 6,7 or 8 with wall

-Wall is necessary but not sufficient to get GCC to play noisily Standard-compliant.
 
You need -std=C90 or -std=C99 (sticking with those standards also supported by XC8; without either of these, GCC compiles the GNU C language which is subtly different to ISO C) and -pedantic, at least. For a wider selection of warnings you also need -Wextra and at least -O2.

Mark (this opinion available for hire)
#28
Page: < 12 Showing page 2 of 2
Jump to:
© 2019 APG vNext Commercial Version 4.5