Arduino IDE V2.3.4 compiler bug

Hi All,

I believe I have discovered a bona fide compiler bug that's demonstrated with this simple script:
As I understand it, j in the for loop is not local to the loop. Do I have this wrong?

void setup() { Serial.begin( 9600 ); while ( !Serial ) ;

int j;

for ( int i = 0, j = 10; i < 5; i ++ )
{
Serial.print( i );
Serial.print( " " );
Serial.println( j );
}
Serial.println( j );
}
The output is:
0 10

1 10

2 10

3 10

4 10

0

The first int j is declared in the context of void setup() and outside of the loop and is not given a value.

A second instance of int j is then declared inside the context of the loop and given a value of 10. It exists only within that context and its value of 10 is printed while the loop is running.

The last print occurs outside the loop and therefore reports the value of the first instance of int j that was declared earlier within the setup() function context. Since this particular instance of the variable has not yet been assigned a value, the value returned is 0.

This is an example of variable shadowing.

https://en.wikipedia.org/wiki/Variable_shadowing

https://stackoverflow.com/questions/31584547/variables-declaration-with-same-name-c

Although syntactically correct and possible to get away with, it is generally considered a bad idea because of the confusion it creates.

2 Likes

That is not the case. A different variable named j is declared as part of the for loop initialisation. It is this variable that is given a value of 10 and is printed in the for loop whilst the other variable with the same name is printed after the for loop

1 Like

Thanks for the clarification.

Hi!

Try to replace the line

for ( int i = 0, j = 10; i < 5; i ++ )

with

for ( int i = 0; j = 10; i < 5; i ++ )
( a semicolon after i=0 )

and run the program again to see the result.

No. That j is an uninitialised local variable and just happens to be zero. The value "returned" when it is used is whatever was in the memory location the compiler uses for it, it could literally be anything.

Using it in that manner also makes for undefined behaviour, which means literally anything can happen.

Which is why the compiler issues a warning.

a7

The result will be an error

Sorry, my explanation here was indeed insufficient. Yes, as it was called on an unassigned variable, the serial.print statement could have returned any unpredictable value within the scope of an int as described. It just so happened that the value was zero in this case.

:+1: :+1:

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.