PIC XC8 signed char literal constants

[NivagSwerdna]

It's only an annoyance but when using XC8...

signed char myThing;

myThing = -1;

The assignment gives a warning due to shortening of the right hand side.

How do I declare an 8-bit -1 value to avoid the warning?

Thanks in advance

[Kalvin]

-1 is of type signed integer, so assigning it to signed char will truncate is, thus the warning.

You can cast is explicitly to a signed char:

Code: [Select]

myThing = (signed char) -1;

Yes, this is very annoying, and it will break the code should you change the type of the myThing.

Some compilers support typeof() function, but unfortunately the XC8 doesn't support that.

However, there is a better way to do it:

Code: [Select]


typedef signed char myThing_t;

myThing_t myThing;

myThing = (myThing_t) -1;



[NivagSwerdna]

But the cast doesn't make the warning go away?

[Kalvin]

Have you tried it?

[JPortici]

compiler version?
i recall having problems with signed chars not being handled as signed, i solved by using a typedef. crazy, whatever.
so, why don't you include <stdint.h> and use the int8_t type? (yeah it just typedef signed char int8_t but you have a standard implementation across compilers and project)

or, assuming you don't run out of memory screw it and use an int

[NivagSwerdna]

Well I tried a few things... cast to (signed char) doesn't work...

main.c:299: warning: (752) conversion to shorter data type

and also...

    typedef volatile signed char myType;
    myType upBtnCount = 0;
    ...
    upBtnCount = (myType)-1;

gives...

main.c:299: warning: (752) conversion to shorter data type

but a slightly more creative...  ((signed char)0)-1 gets rid of the warning and generates the correct code (same as a line with a warning)

!    upBtnCount = (signed char)-1;
0x3E2: SETF upBtnCount, ACCESS
!    downBtnCount = ((signed char)0)-1;
0x3E4: SETF downBtnCount, ACCESS


i.e.  XC 1.36

WARNING          upBtnCount = (signed char)-1;
WARNING          upBtnCount = -1;
NO WARNING    upBtnCount = ((signed char)0)-1;

So I can ignore the warnings or I can do some jiggery pokery.  Very odd but harmless.

[NivagSwerdna]

I found http://www.microchip.com/forums/m815346.aspx

Seems to be a feature.  I'll add a #pragma

[cv007]

Tried it, no warnings for me- XC8 version 1.41

[NivagSwerdna]

Tried it, no warnings for me- XC8 version 1.41

Just tried v1.42 and the 752 warnings are gone.... but now I get lots of...

main.c:140: warning: (373) implicit signed to unsigned conversion

#define UP_LED          LATAbits.LA7

static bit shortFlasher;
...

            UP_LED = shortFlasher;

 

[cv007]

Tried it, no warnings for me- XC8 version 1.41

LATAbits.LA7- shouldn't that be LATAbits.LATA7 ?

[rcbuck]

MPLAB X v3.45
XC8 (v1.42)

This code:

main()
{
    signed char myThing;

    myThing = -1;
   
    while(1)  // main loop
    {
        CLRWDT();

        while(myThing < 125)
        {
            myThing++;
        }
       
        // more code below here

    }  // end while(1)
}  // end main

produces no warning.

[NivagSwerdna]

LATAbits.LA7- shouldn't that be LATAbits.LATA7 ?

I'm not sure what the difference between LATAbits.LA7 and LATAbits.LATA7 is!??!  They look equivalent in struct/bitfield terms?

[NivagSwerdna]

MPLAB X v3.45
XC8 (v1.42)

This code:

####LINE 67    main()
{
    signed char myThing;

####LINE 70    myThing = -1;
   
    while(1)  // main loop
    {
        CLRWDT();

        while(myThing < 125)
        {
            myThing++;
        }
       
        // more code below here

    }  // end while(1)
}  // end main

produces no warning.

Produces 2 warnings with 1.36...

main.c:67: warning: (371) missing basic type; int assumed
main.c:70: warning: (752) conversion to shorter data type

Produces 1 warning with 1.42...

main.c:67: warning: (371) missing basic type; int assumed

The 371 warning seems very sensible.

[cv007]

I'm not sure what the difference between LATAbits.LA7 and LATAbits.LATA7 is!??!  They look equivalent in struct/bitfield terms?

The header for the chip I was using defines all bits in the LATXbits struct as LATXN, not LXN, yours must be different- disregard.

[BrianHG]

I'm curious, I thought that chars & ints were by default signed, and if you didn't want signage, you would use the term unsigned.
Have I been doing thing backwards in XC8?
Or, have I just been lucky that my code always worked using negative numbers just using ints and chars?

[rcbuck]

Produces 1 warning with 1.42...

main.c:67: warning: (371) missing basic type; int assumed

Sorry, my main() is actually void main(void) - I just manually typed main in the reply.

I'm curious, I thought that chars & ints were by default signed

From the XC8 user's manual page 143:
The MPLAB XC8 compiler supports integer data types with 1, 2, 3 and 4 byte sizes as well as a single bit type. Table 5-1 shows the data types and their corresponding size and arithmetic type. The default type for each type is underlined.

TABLE 5-1: INTEGER DATA TYPES

    Type               Size (bits)        Arithmetic Type
unsigned char          8              Unsigned integer

[BrianHG]

Produces 1 warning with 1.42...

main.c:67: warning: (371) missing basic type; int assumed

Sorry, my main() is actually void main(void) - I just manually typed main in the reply.

I'm curious, I thought that chars & ints were by default signed

From the XC8 user's manual page 143:
The MPLAB XC8 compiler supports integer data types with 1, 2, 3 and 4 byte sizes as well as a single bit type. Table 5-1 shows the data types and their corresponding size and arithmetic type. The default type for each type is underlined.

TABLE 5-1: INTEGER DATA TYPES

    Type               Size (bits)        Arithmetic Type
unsigned char          8              Unsigned integer

See attached image:
After reading the finer text 3 paragraphs after the table, signed is the default except for 'char', so, you are correct, though there is no underlining...

[cv007]

That's why stdint.h was invented, so you can just tell the compiler what size you want and whether its signed or not- no table lookup required. When you use a uint16_t, int8_t, uint8_t - its obvious to you, the compiler, and anybody reading your code what that means.

[rcbuck]

though there is no underlining...

No underlining must be your PDF viewer. The screen shot seems to indicate you are running Linux. I see the underlining with Adobe Acrobat.

As you say, the 3rd paragraph down does clarify the data types.

As cv007 suggests, I always use uint8_t, etc... as it makes it clear. I wonder if Microchip is defaulting char to unsigned as a carry over from the ASCII table?

[BrianHG]

No underlining must be your PDF viewer. The screen shot seems to indicate you are running Linux. I see the underlining with Adobe Acrobat.

Sorry, but I am running windows 7.
And I am using Adobe Acrobat Reader version 2017.009.20044, Copyright 1984-2017 Adobe Systems Incorporated.

[rcbuck]

Brian, I was using the XC8 manual from 2012. I just downloaded the XC8 2012-2016 version. I do not see the underlining in that version even though they state default types are underlined. You gotta love Microchip.

I am running the same version Acrobat that you are. However, I am using Windows 10, which sucks compared to Windows 7.