Re: [avr-gcc-list] Passing a string variable to lcd_puts

[David Kelly]

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, address@hidden
========================================================================
Whom computers would destroy, they must first drive mad.