On Fri, Mar 27, 2009 at 04:21:15PM -0400, David VanHorn wrote: > > > > As you should be. Plain old "char" *is* either signed or unsigned > > depending on your choice of compiler. And in effort to build code > > that runs as expected better compilers have a compile time switch to > > control code generation when the signedness is specifically > > indicated. > > Ok, that's one of the reasons that I'm using the new types, but I > still don't understand why I'm getting the signage warning when I use > uint8_t or int8_t to feed chars to lcd_puts. Is int8_t not signed?
Yes, int8_t is signed. Is defined in <stdint.h> as: typedef signed char int8_t; and uint8_t is: typedef unsigned char uint8_t; > And why does lcd_puts want signed chars anyway? > Isn't "negative A" nonsense? I think its nonsense, but the origins of convention date way back and might have something to do with the original practice of using signed int for everything. A value might move in and out of signed char out and in to signed int easier than for an unsigned char. Am not familiar with lcd_puts(). Have always written my own LCD code. Somethings are easier to write than to understand what someone else did. Meanwhile the point about -funsigned-char and family was a hint to look into what you are currently running and what was used when lcd_puts() was compiled. Sad, but current project is using Visual Studio 2008 Express where the C compiler has also thrown complaints for mixing signs. And for "precision loss" when stuffing 32 bits into 8. Generates exactly the same code without complaining if I write u8 = ( u32 & 0xff ); -- David Kelly N4HHE, dke...@hiwaay.net ======================================================================== Whom computers would destroy, they must first drive mad. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
