| View previous topic :: View next topic |
| Author |
Message |
E_Blue
Joined: 13 Apr 2011
Posts: 416
|
| Condition always FALSE? Why? |
 Posted: Fri Apr 17, 2020 2:14 pm |
 |
|
Scenario:
MPLAB X IDE 5.35
CCS v5.091
PIC24FJ1024GB606
I have a function that deletes and search some free space in a flash memory and I'm getting the Warning Condition always FALSE Why?
The function ReadFlashBytes must fill FlashBufferIn buffer and even if not how the compiler knows that the condition will always be false?
Is this another of those "false warnings"?
| Code: | #define FlashBufferInSize 128//256
#define FlashBufferOutSize 128//256
char FlashBufferIn[FlashBufferInSize];
char FlashBufferOut[FlashBufferOutSize];
unsigned int16 SearchFreePosition()
{
unsigned int16 x,y;
for(x=0;x<=0x3FFF;x+=32)//128/32=4096 = 1 Block
{
output_toggle(GreenLed);
restart_wdt();
ReadFlashBytes((unsigned int32 ) x*128,3);
if(FlashBufferIn[0]==0xFF && FlashBufferIn[1]==0xFF && FlashBufferIn[2]==0xFF)// Condition always FALSE???
{
DeleteBytesEE((x+4096),32);
return x;
}
}
//....More code
} |
_________________
Electric Blue |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Apr 17, 2020 2:39 pm |
|
|
Make the changes shown in bold below. In PCD, everything is signed by default.
| Quote: | unsigned char FlashBufferIn[FlashBufferInSize];
unsigned char FlashBufferOut[FlashBufferOutSize];
|
|
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1317
|
|
| Posted: Fri Apr 17, 2020 2:59 pm |
|
|
Just as additional info, the reason the signed/unsigned matters is due to the size of what you are comparing.
The literal 0xFF is 16bit by default and has an actual value of 0x00FF.
Your character as PCM_Programmer shows is signed and is 8bits.
In C if you compare an 8bit to a 16bit, the 8bit has to be converted to 16bit before the comparison. So if your character had a value of 0xFF, when it is expanded to 16bits, it sign extends the value, making the 16bit representation of your character 0xFFFF.
Then the code compares the 0xFFFF to 0x00FF, which will always fail. In the old days the compiler didn't catch this and warn you. Nowadays it can tell that you can never succeed at that comparison due to the sign extension and lets you know.
I ran into this problem almost 9 years ago when they made the change from default unsigned char to default signed char:
https://www.ccsinfo.com/forum/viewtopic.php?t=45702&highlight=char |
|
|
E_Blue
Joined: 13 Apr 2011
Posts: 416
|
|
| Posted: Fri Apr 17, 2020 3:41 pm |
|
|
Thanks! It is working now.
_________________
Electric Blue |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19219
|
|
| Posted: Sat Apr 18, 2020 2:38 am |
|
|
This has caused me repeated grief....
Having the 'char' default to 'signed' is sometimes quite annoying.
It's 'dependant on platform' in the C specifications. However interestingly
The C standard also defines that "all members of the basic execution
character set have non-negative values". This is of course by default
the 7bit ASCII set, which still fits into the 'signed' type.
Far more compilers have the 'char' as signed now than as unsigned,
so it's a thing to be aware of. Using 'byte' as the type for the buffers
avoids this problem, and makes a lot of sense....  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
