Xc8 v2.00 C standard c99 versus c90 question

Thread Starter

Picbuster

Joined Dec 2, 2013
1,047
The statement in C90
for (i=0;i<=Card.Lenght;i++){Card.Valid += (unsigned int)(Card.Array[i+Card.Offset*Card.Lenght] == Buff_In);}

simplified written ;
result += (a==b); // is correct C no error.
But it will create an error when I use the C99 standard.
but it did accept result = result + (a==b) ; // this looks to me a silly way!

But I was not able to find any documentation about this.

Do you guys have an answer?

Picbuster
 

nsaspook

Joined Aug 27, 2009
13,086
What is the error code? You have a a==b equivalence test that results in a boolean result added to an integer variable to count how many (of a set of bools) are true. The standard does have a a rule to convert to int and false = 0 and true = 1 (usually) but treating bool like it is an integer type is usually considered bad form.
 

Papabravo

Joined Feb 24, 2006
21,159
The error is a result of the rules on implicit type conversion in expressions. In C90 the expression (a == b) was probably represented as an integer with values of 0 and 1. In later implementations the expression has the values 'true' and 'false'. On top of that the compiler might not be able to cast the Boolean values to integers so it could evaluate the expression. You did not tell us what the error was so we could confirm the hypothesis. Why would you leave out such a crucial piece of information. Do you think we are omnipotent pre-cogs?
 

mckenney

Joined Nov 10, 2018
125
My copy of C99 (sec 6.5.9 para 3) says:
"The == (equal to) and != (not equal to) operators [...] Each of the operators yields 1 if the specified relation is true and 0 if it is false. The result has type int."
(I had to look, since I couldn't believe they would/could change this after 40+ years.)
 

Papabravo

Joined Feb 24, 2006
21,159
My copy of C99 (sec 6.5.9 para 3) says:
"The == (equal to) and != (not equal to) operators [...] Each of the operators yields 1 if the specified relation is true and 0 if it is false. The result has type int."
(I had to look, since I couldn't believe they would/could change this after 40+ years.)
That is why I asked for the actual error. I remember this discussion and at some point this treatment was deprecated in one or more of the standards..
 

spinnaker

Joined Oct 29, 2009
7,830
The statement in C90
for (i=0;i<=Card.Lenght;i++){Card.Valid += (unsigned int)(Card.Array[i+Card.Offset*Card.Lenght] == Buff_In);}

simplified written ;
result += (a==b); // is correct C no error.
But it will create an error when I use the C99 standard.
but it did accept result = result + (a==b) ; // this looks to me a silly way!

But I was not able to find any documentation about this.

Do you guys have an answer?

Picbuster

I compiled your code with 2.0 and it works fine.

Though the IDE does not seem to like V2.0. Need to see if I have to upadte the IDE.
 

Thread Starter

Picbuster

Joined Dec 2, 2013
1,047
Thank you all for the responce.

I used the latest IDE Spinnaker you could right .
My next step is to test xc8 v2.0 with an older IDE.
Additional information all under Linux mint 18.2


Papabravo: I will reconfigure my system sometime next week and recreate error.
But this should have nothing to do with integers/ boolean hence result = result + (a==b) is working as it should be no errors.

Picbuster
 
I looked at this a bit this morning using MPLAB X IDE v5.05 and XC8 V2.00
My XC8, 2.00 Global option is set to C99.

XC8Option.jpg

I used only this this source code in main:
C:
void main(void) {
  int result,a,b;
  a=0;
  b=1;
  result=2;
  result += (a==b);
  return;
}
If I set the device to a 10F320 (leaving the option as C99), I see no errors. But, I see an advisory message twice:

::: advisory: (2049) C99 compliant libraries are currently not available for baseline or mid-range devices, or for enhanced mid-range devices using a reentrant stack; using C90 libraries

Which makes sense because C99 is unavailable for lower end chips (and BTW, XC8 versions below 2.00). Also, the file that is throwing the advisory is printed out right before the advisory (it is long, and I have not included them here, but I think that they give a clue).

If I set the Global option to C90 and rebuild, those two aforementioned advisory messages go away. But, however, the advisory below appears:

Non line specific message::: advisory: (1492) using updated 32-bit floating-point libraries; improved accuracy might increase code size

Next, I change the device to a 16F18875 and I compile the exact same source.

With the option still set to C99, it compiles fine with no errors and no advisories.

If I set the option to C90, I DO get a warning:

C:\Program Files (x86)\Microchip\xc8\v2.00\pic\sources\c90\pic\__eeprom.c:73:33: warning: (373) implicit signed to unsigned conversion

and the advisory:

Non line specific message::: advisory: (1492) using updated 32-bit floating-point libraries; improved accuracy might increase code size

But, it looks to me, that the warning is not from my main.c but rather a supporting file __eeprom.c and you can click on the warning and see the offending line.

I don't know if this has anything to do with what the TS saw. There are certainly vagaries in XC8 and I think this one is related to integrating new floating point libraries into 2.0 and some kind of interaction with implementation of the two standards as an option (for compatibility with older code I would guess). Since my global option is normally set to C99 with 2.0, I'm not much concerned, but if anyone knows more, I am all ears.



 

nsaspook

Joined Aug 27, 2009
13,086
There shouldn't be any problem with the implicit promotion of bool to int but as a matter for programming form it's better to use a explicit boolean conversion to int for source code clarity.
https://syntaxdb.com/ref/c/ternary mybool ?1:0;

C:
for (i=0;i<=Card.Lenght;i++)
{
      Card.Valid += (unsigned int) (Card.Array[i+Card.Offset*Card.Lenght] == Buff_In);
}

for (i=0;i<=Card.Lenght;i++)
{
      Card.Valid += (Card.Array[i+Card.Offset*Card.Lenght] == Buff_In)  ? 1: 0 ;
}
The XC8 2.00 compiler generates the exact same code for both forms in this test spliced into another xc8 2.00 project.
C:
typedef struct card {
   int Valid, Lenght, Offset, Array[16];
} card;

struct card Card={
   .Lenght=15,
   .Offset=1,
   .Valid=0,
};

int Buff_In = 0, i;

void main(void)
{
   // Initialize the device
   SYSTEM_Initialize();
   PIN_MANAGER_IOC();

   // If using interrupts in PIC18 High/Low Priority Mode you need to enable the Global High and Low Interrupts
   // If using interrupts in PIC Mid-Range Compatibility Mode you need to enable the Global and Peripheral Interrupts
   // Use the following macros to:

   // Enable high priority global interrupts
   INTERRUPT_GlobalInterruptHighEnable();

   // Enable low priority global interrupts.
   INTERRUPT_GlobalInterruptLowEnable();

   // Disable high priority global interrupts
   //INTERRUPT_GlobalInterruptHighDisable();

   // Disable low priority global interrupts.
   //INTERRUPT_GlobalInterruptLowDisable();

   // Enable the Peripheral Interrupts
   INTERRUPT_PeripheralInterruptEnable();

   // Disable the Peripheral Interrupts
   //INTERRUPT_PeripheralInterruptDisable();

   for (i = 0; i <= Card.Lenght; i++) {
     Card.Valid += (unsigned int) (Card.Array[i + Card.Offset * Card.Lenght] == Buff_In);
   }

   for (i = 0; i <= Card.Lenght; i++) {
     Card.Valid += (Card.Array[i + Card.Offset * Card.Lenght] == Buff_In) ? 1 : 0;
   }

   while (true) {
     APP_Tasks();
   }
}
 

Thread Starter

Picbuster

Joined Dec 2, 2013
1,047
Thank you all for the effort and time you guys spend to help me.
I encountered a few other problems with eeprom r/w and SPI and wend already back to my old xc8 1.34 & ide 2.15.
reason: can't afford to lose project time rewriting solutions for all incompatibilities between the xc8 levels.

I regret that Papabrovo put me on his ignore list.


Picbuster
 

spinnaker

Joined Oct 29, 2009
7,830
Thank you all for the effort and time you guys spend to help me.
I encountered a few other problems with eeprom r/w and SPI and wend already back to my old xc8 1.34 & ide 2.15.
reason: can't afford to lose project time rewriting solutions for all incompatibilities between the xc8 levels.

I regret that Papabrovo put me on his ignore list.


Picbuster

What is this 4 posts nopw and we still don't know what error you were getting in your TS, For somone that wants help, you certainly are not being very cooperative. I can't blame PB for not wanting to waste any more time on you.
 
Top