Lpc2000

I am using arm-elf-gcc and get a compiler warning for the following
code:

 

typedef unsigned char uint8_t;
void main (void)

{

  uint8_t txBuf[25];

  strcpy(txBuf, "number");

}

 

above code produces:

warning: pointer targets in passing argument 1 of 'strcpy' differ in
signedness

 

"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.

 

Thanks for the help.

Matt

 



[Non-text portions of this message have been removed]

Hello,

> From: Matthew Kavalauskas
> To: gnuarm@yahoogroups.com
> Sent: Friday, May 27, 2005 4:54 PM
> Subject: RE: [gnuarm] warning: pointer targets in assignment differ in 
> signedness

> From: "Matthew Kavalauskas" <mkavalauskas@...>
> To: <lpc2000@yahoogroups.com>
> Sent: Saturday, May 28, 2005 2:33 PM
> Subject: [lpc2000] char - signed or unsigned

were the answers in the "gnuarm" mailinglist not sufficent enough ? There 
Dave Murphy already answered your question.
I think, if you want to get a final answer (because your question is mainly 
independent of any system), you should choose a general "C" mailinglist / 
newsgroup or post the question to some mailinglist / newsgroup which is gcc 
related !

Regards,

        Martin

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/

> were the answers in the "gnuarm" mailinglist not sufficent enough ?
There 
> Dave Murphy already answered your question.
> I think, if you want to get a final answer (because your question is
mainly 
> independent of any system), you should choose a general "C"
mailinglist / 
> newsgroup or post the question to some mailinglist / newsgroup which
is gcc 
> related !
> 

No - they were not sufficient.  I already understood his first rather
short statement and only saw his second reply just now which was
equally not enlightening.  Also, I have been a part of both mailing
groups for a few weeks now, and I assumed from the volume of posts to
LPC2000 compared with gnuarm (particularly ones that got
responses/answers) that I was more likely to get assistance in LPC2000.

Thanks to Robert for the much more complete answer; however, I still
have questions.  I will continue this thread on the gnuarm user group
as this is a question about the gnuarm compiler.

Matt

> 
> No - they were not sufficient.  I already understood his first rather
> short statement and only saw his second reply just now which was
> equally not enlightening.  

My apologies to Ian.  I realize he made the second post rather than Dave.

Matt