The way I deal with this is to think of "char" as a distinct type different than unsigned or signed char. The compiler certainly thinks that way. So, either keep all your type's the same, or, cast. But don't mix and match char with the others - the compiler is complaining because it will mess your code up!
To reiterate: don't assume signed or unsigned for "char" you will be bitten. I was, just yesterday, bitten where comparing a "char" to 0xB0 failed, but comparing a uint8_t succeeded (and made for smaller code.) Another way to deal with the typeness of stuff is to make the type explicit. Either cast the constant: #define cHeader ((uint8_t)0xB0) or make a local variable that the compiler will throw away when it is done: static const uint8_t cHeader = 0xB0; In my case, yesterday, I cheesed out and just made the input type "uint8_t" and moved on. If I was not in a hurry I would have made the constants type explicit. I'll probably pay for that decision sometime in the future when the code breaks and I spend an hour or four figuring it out, again. Oh, yeah: Job security! YMMV From: avr-gcc-list-bounces+larry=barello....@nongnu.org [mailto:avr-gcc-list-bounces+larry=barello....@nongnu.org] On Behalf Of David VanHorn Sent: Monday, March 30, 2009 10:15 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts I am still very puzzled over why the compiler balks wether I use signed or unsigned chars to feed lcd_puts. When I used "unsigned char" it balked. When I used "char", it didn't. Now when I use int8_t or uint8_t, it balks. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.21/2014 - Release Date: 03/30/09 08:40:00
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
