Basic overflow, type size, and Serial.print unexpected behavior

Using Arduino Programming Questions
1

Trying out a couple of things and got unexpected behavior from printing an int value.

Questions:

  1. Why is it behaving like this?

  2. How do I fix it so that I have a counter that rolls over at a 16bit boundary?

    Did this test:
    Test the rollover of in int variable in a for loop.
    Set the the for loop to execute forever.
    Expected behavior is for something to happen at the 16 bit positive rollover limit for an int.
    Instead, the numbers in the serial monitor go way over the limit for an int. I stopped running it with this output:

1504007
1504008
1504009
1504010
1504011
1504012
1504013
1504014

code:


void setup() {

  pinMode(arduinoLED, OUTPUT);    // Configure the onboard LED for output
  digitalWrite(arduinoLED, LOW);  // default to LED off
  Serial.begin(115200);
  Serial.println(F("Ready"));
}

//******************************************************************
void loop() {
int limit = 1;
  for (int count = 0; limit > 0; count++) {
    Serial.println(count);
  }
}
2

What device are you running on? Maybe an int is not 16bit?

An Int will overflow at 32767 on an Arduino, so if you want to see what happens easier try...

int count = 32760;
void loop()
{
  Serial.println(count++);
  delay(500);
}
3

You could try sizeof() and run it on int and count

Serial.print("Size of INT: ");
Serial.println(sizeof(int));

It'll give you the number of bytes
Also check out int16_t, uint16_t

4

Hmmm.

5

Thank you for the replies.
I am still no closer to knowing how it can print numbers greater than the positive int limit.
Nano is the device I am using. so it should be 16 bit.

adding "sizeof" shows 2, so yeah it should be 16 bit.

size of = 2
67065
size of = 2
67066
size of = 2
67067

code with sizeof 

#define arduinoLED 13  // Arduino LED on board
void setup() {
  Serial.begin(115200);
  Serial.println(F("Ready"));
}

//******************************************************************
void loop() {
  int limit = 1, a;
  for (int count = 0; limit > -1; count++) {
    Serial.println(count);
    Serial.print("size of = "); Serial.println(sizeof(count));
  }
}
6

I am perplexed as to why the results are over the limit with type int. Any help would be appreaciated.

What if unsigned int is used in place of int?
This provides the expected result, a roll over at the maximum value for a 16 bitunsigned number:
65530
65531
65532
65533
65534
65535
0
1
2
3
4

code with unsigned int. Also set limit back to > 0 instead of -1. It works the same. The -1 was left over from a different test.

#define arduinoLED 13  // Arduino LED on board
void setup() {
  Serial.begin(115200);
  Serial.println(F("Ready"));
}

//******************************************************************
void loop() {
  int limit = 1, a;
  for (unsigned int count = 0; limit > 0; count++) {
    Serial.println(count);
    //Serial.print("size of = "); Serial.println(sizeof(count));
  }
}

I do not understand these results. Next is the try and check if Serial.print is showing the value in 'count' or if it is in error.

7

Interesting...

This code give expected results...

int  count = 32760;

void setup() 
{
  Serial.begin(115200);
}


void loop()
{
//  for (int count = 32760; ; )  // This line makes all the difference
  {
    Serial.println(count++);
    delay(500);
   }
}

If the for line is uncommented, then it does not overflow at 32,767.

I expect the compiler has determined that count will never be negative, so internally has actually assigned as unsigned.

1 Like
8

In C and C++, the behavior of signed integer overflow is “undefined.”

9

Prior discussion:

10

Okay, that explains the bad behavior. Serial print may be showing the number as it overflows into who knows where.
Adding some error checking will work.

Thanks for the follow up tesing and suggestions. I will try using volatile or static.
'volatile int' is working as expected now!

Thanks.

P.S. This was an exercise to understand the odd behavior of the functions and it is not actually going to be used. Using volatile this way works on this hardware but the overflow behavior of int is still undefined. The value should be kept within bounds in some other way for example unsigned integer overflow reliably wraps around.

1 Like
11

Thanks for posting the update!

12

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