From: david.br...@hesbynett.no
[...char vs. signed cahr vs. unsigned char...]

> 
> Don't look it up - if you learn the compiler's default behaviour, you 
> risk writing incorrect code. If it is in any way relevant whether a 
> char is signed or not, write "signed char" or "unsigned char" explicitly 
> in the code. The only reason one would ever use a plain "char" is to 
> hole a true character - a letter - such as in strings. Since it is (in 
> general) meaningless to do arithmetic on characters, it does not matter 
> if the compiler considers them to be signed or unsigned.


All true, but you need to be careful all the same.  Consider the case I ran 
into about 20 years ago, a custom terminal with "Function" keys (e.g., F1, F2, 
etc) that returned values outside the standard ASCII range (0xF1, 0xF2, etc.).

 

Consider the following code, stubbed out for illustration purposes:

 

#define EXIT_KEY 0xF1

 

extern void process_key(char key);

 

char get_key(void) {return EXIT_KEY}

 

void handle_input(void)

{

   char key;

 

   do

   {

      key = get_key();

      process_key(key);

 

   } while (key != EXIT_KEY);

}

 

In this code, the handle_input function falls into an infinite loop if plain 
char is signed.  This is because key gets promoted (to signed int) before the 
comparison  with EXIT_KEY (which is already signed int).  If plain char is 
signed, and key is 0xF1, the sign is extended for key, but not EXIT_KEY.

 

There are numerous solutions, but I post it here as a warning to the wise.  
Sometimes math is performed on character types implicitly.

 

Regards,

 

   -=Dave

 

_________________________________________________________________
Express your personality in color! Preview and select themes for HotmailĀ®.
http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Reply via email to