Lpc2000

At 05:33 AM 5/28/05 -0700, Matthew Kavalauskas wrote:
>typedef unsigned char uint8_t;
>void main (void)
>
>{
>
>   uint8_t txBuf[25];
>
>   strcpy(txBuf, "number");
>
>}

<snip>

>"number" seems to be created as signed char.  My understanding is that
>char is (in general) undefined whether it is signed or unsigned.
>Specific compilers choose one or the other, but code should not assume
>one or the other if the goal is portability.  I found some information
>stating that arm-elf-gcc defines char as unsigned, so I shouldn't get
>the warning in the first place.  Additionally, the flag -funsigned-char
>for arm-elf-gcc should force it to be unsigned, but adding the flag
>still produces the warning.  Can anyone suggest how to get rid of it?  I
>would strongly prefer my char to be unsigned.

An amplification on the replies you received on gnuarm.  There are three 
distinct 'character' types in C

char
unsigned char
signed char

Even when you set the signedness of char it remains a distinct type from 
the other two.

Strings are best dealt with a type char (conceivably as a wide character in 
some circumstances).  Casting a string pointer from char * to another type 
is just an exercise in excessive casting with no benefit.  String 
manipulation rarely depends on signedness.

OTOH when you use a character type to hold a number then it makes a lot of 
sense to explicitly choose the signedness and that's where types like 
unit8_t are useful.

It's also important to note that character literals like  'T' are of type 
int not type char.

This is all standard C language stuff and dealt with frequently on forums 
such as comp.lang.c.

On an ARM specific note.  If you use a character type to hold 8 bit values 
you may save a little space to hold the variable but it may take more code 
to deal with it.  In some cases you won't even save the memory space.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/