BUG? - initialisation of integer with -1 fails! Please confirm


I'm new to arduino programming, but I think I have found a bug. The following code is compiling and updating and there are no errors (I'm using Arduino Uno R3 and the Arduino IDE version 1.0.5):

int LED = 13;
int number = -1;

void setup(){

void loop(){
  if(number == -1)
    digitalWrite(LED, HIGH);

I guess, I don't have to explain the code, it's pretty simple: If "number" is the initialized value of -1, then the LED should light up.
Nevertheless, the LED is not lighting up! But if I change from -1 to any other number, for example 2, then it works.

int number = 2;
if(number == 2)

-> LED lights up.

I wanted to figure out, what the variable "number" is in the "-1" case, and therefore wanted to communicate via RS232. It turns out, if I add Serial.begin(9600); to the setup-function, then the LED also lights up in the "-1" case.

What is going on here? Can someone please confirm the behaviour, so that we can report a bug, or did I miss anything?

Thanks, bumberle

Have you tried using a different name for the variable you are calling "number"?


Hello Robin2,

thanks for your answer. I just tried "asdf" instead of "number", but it gives me the same results: works for "2", but not for "-1".


Here's two more data points for you. If I initialize with 2, and then, in setup, write number = -1;, it works as expected.

Aslo, if I change the order of the two declarations to:

int number = -1;
int LED = 13;

it works as expected.

I'd call it a bug.

Your original code works for me on a Nano (and a Teensy 2).


That's really surprising, I can confirm that simply changing the order of the declarations "solves" the problem. I will write a posting in the "Suggestions for the Arduino Project"-section and report the bug. Thank you all for looking into this.

There is a known bug in some of the bootloaders. I think it goes like this: -1 is 0xFFFF in hex, and 0xFFFF is what the chip is initialized to when it is erased. Some bootloader code stops at the last 0xFF in the hex file thinking it is unnecessary to upload any more, but due to some coding issues it actually places random data there.

I can confirm that simply changing the order of the declarations "solves" the problem.

That doesn't surprise me, as that probably moves that final 0xFF to be not the last byte in the hex file. (Your example shows this).

One thread about it here:


I can reproduce the same bug with a UNOR3 and 1.0.4. It's bizarre - the problem goes away due to trivial code changes that ought logically to have no effect. Looking at the C++ source generated from the sketch does not reveal anything to cause this behaviour.

It's nothing to do with the code, excepting that it ends with 0xFF. Can you post the code that reproduces it?

Thanks Nick Gammon, to shine some light onto this. I read your linked thread and tried to understand it, although it goes far beyond my knowledge of coding (bootloaders, etc.). I assume from this post

I guess that one of the reasons that this doesn't seem to cause many problems is that if you use any arduino library that has .data, it will show up AFTER the user variables and prevent the problem...

that if using SERIAL communication, some additional data is implicitly added after the last declaration of "int number = -1" and therefore the "-1" or 0xFF is not the last byte in the hex file.

So, to easily avoid the problem, I will never have a "-1" as my last part of the declarations. If necessary, I will just add a dummy variable that never will be used, but that is not initialised to "-1".

That will probably do it, assuming the compiler doesn't shuffle variables around.

Another way would be to initialize variables in setup() ... especially if they are not zero. Global variables default to zero anyway.