Arduino bug? Please run this code to check (RESOLVED: NOT A BUG)

Could someone please run this code and post the output? It's a simple program designed to convert an ASCII encoded number into an int.

void setup(){
  Serial.begin(9600); //Initialize serial port
}

void loop(){                //The main loop
  //initialize a variable to hold the int value
  int out_put = 0;
  //debug 
  //Serial.println("Hello world");
 //While there is a character in the buffer
  while (Serial.available() > 0)
  {
    //Read a digit from buffer
    char digit = Serial.read();
    //Convert to decimal represendation
    digit = digit - '0';
    //multiply by 10
    //and then add value to out_put
    out_put *= 10;
    out_put += digit;
  }
   Serial.println("Output is ");
   Serial.println(out_put);
   while (Serial.available()==0)
   {}
}

The output I currently get for an input of '12' (at the arduino Serial monitor) is

Output is 
1
Output is 
2

However, un-commenting the "serial.println("hellow world") line fixes the problem and the program works as it should..
Then the for the input '12', the output is also 12.
what's happening?

I don't think this is a bug. I have not run the code, but it seems to me that the program should work just like you described it. The loop runs and reads the first digit 1. Then it stops on the empty loop until the next letter is available, and starts again. Putting the hello world line there probably keeps the program busy enough so that both letters arrive in the internal serial buffer.

A quick fix would be to put a "if(Serial.available() > 1)" around the value processing code, but of course, then it wont work with one-digit numbers.

One more thing.

If you really want to receive numbers from a computer as ASCII values, you need to somehow notify the arduino how many digits the number occupies. For example, you could send "512345", where the first number is the length and the rest is the actual numbers. Another (arguably better) way would be to not send ASCII values at all and just send the numbers as binary data. In my opinion this is much cleaner anyway and you can send huge values in just a few bytes.

Thanks.. please run the code if possible. The println line does seem to have an effect on the output of the program. That's why I think it is a bug.

I too prefer to send the data as bytes, but this seems to be quite difficult to do. (I use python for programming on the PC) I've posted another thread on that subject here.

For now, I'm more concerned with this "bug".

Oh ... looks like it had to do with timing.
I put a delay statement inside the while loop just before it read from the buffer and now things seem to work properly.
BTW : If you have a suggestion of how to send number over serial more efficiently, please post in the other thread (or this one).

Again, this is not a bug, but as you said, a timing issue. The delay caused the buffer to fill up, as did the print command with hello world. If you don't mind the delay you can go with the current setup. Just remember that if, for some reason, there is old data in the buffer, your code will read that as well and mess up the number conversion.

Thanks.. please run the code if possible. The println line does seem to have an effect on the output of the program. That's why I think it is a bug.

As you've been told/discovered it is NOT a bug. You have unrealistic expectations.

I put a delay statement inside the while loop just before it read from the buffer and now things seem to work properly.

Lousy solution.

The delay caused the buffer to fill up, as did the print command with hello world.

The delay did not CAUSE the buffer to fill. It (like the delay imposed while printing data to the serial port) ALLOWED the buffer to fill.

If you have a suggestion of how to send number over serial more efficiently, please post in the other thread (or this one).

You should not be running two threads talking about the same problem.

You should also get a better understanding of how serial data transmission works, so that you can read the data as fast as it is sent. The key to this is, of course, knowing when a complete packet has been received. This can be because you know how many characters make up a complete packet (and you are real lucky and no bytes get lost/mangled) or because there is something that marks the end of a packet. Sending "<12>", and reading whatever data is available until you see the '>' will allow you to get a complete packet, with no delays, as fast as possible, no matter how slow/fast the serial connection is.

bool started = false;
bool ended = false;
int serValue = -1;

void loop()
{
   while(Serial.available() > 0)
   {
	 char aChar = Serial.read();
	 if(aChar == '>')
	 {
	     started = true;
	     ended = false;

	     serValue = 0;
	 }
	 else if(aChar == '>')
	 {
	     ended = true;
             break;
	 }
	 else
	 {
	     if(started && aChar >= '0' && aChar <= '9')
	     {
		   serValue *= 10;
		   serValue += aChar - '0';
	     }
	 }
   }

   // Done processing pending serial data

   if(started && ended) // Have we got a complete value?
   {
	 // We have, and the integer is stored in serValue...
   }
}

PaulS:
The delay did not CAUSE the buffer to fill. It (like the delay imposed while printing data to the serial port) ALLOWED the buffer to fill.

You are quite right. Poor choice of words by me...

@PaulS
Thanks for the code you posted.

By the way,I would like to point out that I'm not referring to the same problem in both threads. The other thread is about different methods used to send data over serial communications.
This current thread is about resolving a problem I encountered while trying to pass serial data to the arduino using a method that I found from google.

The other thread is about different methods used to send data over serial communications.

OK. My apologies.