signedness compiler warnings (WinAVR)

jmr1972 wrote on Monday, June 16, 2008:


I like the new interface for the sendFromISR functions it makes it possible to figure out if a queue is full or not (always useful if you’re trying not to loose data :slight_smile: )
When migrating my project to the latest and greatest I noticed a compiler warning (it’s trivial but if no one tells you how will you know about it?)

In the documentation for the new type interface of the *sendFromISR functions you show the 3rd parameter to be portBASE_TYPE however gcc complains about pointer signedness difference for these functions. This is normal as the function prototypes are specified with signed portBASE_TYPE. To eliminate the warning the programmer simply needs to specify the variable he’s used for the third parameter as a signed portBASE_TYPE…

Either is fine as far as I’m concerned maybe a quick fix-up of either would avoid others the same wonderment…

What’s the reason for the specific signed portBASE_TYPE argument? Is it really useful to have it as signed? Just a thought…


rtel wrote on Monday, June 16, 2008:

The signed/unsigned qualifier is a portability issue when using 8 bit devices - some of which will have chars signed by default, and others unsigned.  Its a pain.  I think this actually changed between WinAVR versions.  Are you using the latest version, or an older version?

If you are using a 16 or 32bit device then the base type is always signed by default, so the extra qualifiers are there just to keep the 8bit compilers happy - not doing a good job in this case!


jmr1972 wrote on Tuesday, June 17, 2008:

I’m using the 20071227 version I haven’t updated to the June of this year one yet and not sure if I will as there are no improvements/fixes for my platform (ATMega640).

My thinking about the signed/unsigned on 8bit platforms is that since it varies from compiler to compiler why not just let the compiler do its job. In the majority of cases we don’t care whether a char is signed or unsigned. Since you define a new data type portBASE_TYPE then why not make that a signed char or unsigned char?

Now this is a minor point, and an easily “fixed” one for the user, but I think that this would improve newcomers’ first impressions of FreeRTOS. Me? I’m a convert :slight_smile: I really do like the RTOS and it’s simplicity. Yes there are areas that could do with improving but hey so are on my car, house, job, life in general :slight_smile:
Keep up the great work… I’ll be there to check the AVR Mega side of things.