Go Down

Topic: Obscure infinite for loop. (Read 1 time) previous topic - next topic

Tom Carpenter

Any suggestions why this would result in an infinite loop? Is there something about char that has changed with regards to the due.

Code: [Select]

char i;
byte mask = 0x80;
for (i = 7;i >= 0; i--){
#ifdef _LIB_SAM_
digitalWrite(_SCLK, 0); //Clock 0
digitalWrite(_SDATA, data & mask); //Send a bit
mask >>= 1;
#ifdef _LIB_SAM_
digitalWrite(_SCLK, 1); //Clock 1

Tom Carpenter

Answered my own question. It would appear that char is now unsigned by default? It would be useful if that was mentioned somewhere!


I thought char has always been unsigned  :~

Anyway that's a good reason to use the uintX_t types.

Rob Gray aka the GRAYnomad www.robgray.com


Dec 09, 2012, 02:01 am Last Edit: Dec 09, 2012, 02:24 am by fat16lib Reason: 1
In the original C standard the char type was not specified as signed or unsigned.  This presented problems when char was used as a number.

Rather than change the behavior of char in existing implementations, the standards committee added two new types, signed char and unsigned char.  So now there are three types of char.  

So you should never use char as a numerical type, only unsigned char or signed char.

It is even possible that two compilers for a given machine will have different numerical behavior for char.

You can have three overloaded functions, f(char), f(signed char), and f(unsigned char).

For all other integer types there are two types, for example int is the same type as signed int.  You can only have two overloaded functions with f(int) being the same as f(signed int).

Edit: I just remembered that with gcc you can have "char" signed or unsigned with flags -funsigned-char or -fsigned-char.


I ran into something very similar to this a little over a year ago and got into some serious C standard "discussions" over
how incrementing chars are handled in loops.
Here is the AVR freaks thread:
The standard does have some areas that are not specified to allow leniency for implementors.
The problem I had is that depending on how the char variable was declared, automatic vs static
or the level of optimization used or whether additional functions were passed the variable as an argument
varies how the increment of the "char" type is handled and subsequently tested or passed to a sub function.
In my book , it is case of overly aggressive optimization generating incorrect code in certain
However it technically can't be be considered as wrong because
the standard doesn't explicitly state how to handle math on type "char" for all cases.
So the compiler guys can always just claim that the unexpected (wrong) behavior was undefined anyway.

My beef was that while a standard may claim that a particular behavior is unspecified, it should
at least be consistent within the implementation.

--- bill

Go Up