Is size of int type correct?

Status
Not open for further replies.
Q

quadrupel

Well-known member
I've been bashing my head for a bit, and I've discovered something confusing. I have been assuming the int type has a size of 2 bytes and I've discovered that it's 4. is this correct? Here is a small program showing the head scratcher. Normally, short and int have the same 2 byte size.

Comments?

Code: 
/*
Teensy 3.5 Output
Show Integer and Float Data Sizes

long long is 8
long is .... 4
int is ..... 4 <-- I expected 2, why 4?
short is ... 2
char is .... 1
double is .. 8
float is ... 4
*/
void setup()
{
  Serial.println("Show Integer and Float Data Sizes\n");

  Serial.print("long long is "); Serial.println( sizeof(long long) );
  Serial.print("long is .... "); Serial.println( sizeof(long) );
  Serial.print("int is ..... "); Serial.println( sizeof(int) );
  Serial.print("short is ... "); Serial.println( sizeof(short) );
  Serial.print("char is .... "); Serial.println( sizeof(char) );
  Serial.print("double is .. "); Serial.println( sizeof(double) );
  Serial.print("float is ... "); Serial.println( sizeof(float) );

}

void loop()
{
 
}
 
If size width is important, use int32_t, uint32_t, int16_t, uint16_t...

also note, double is 8 bytes (and its not =float like on AVR)
 
El_supremo and Frank,
Thanks for getting back back to me so quickly. I knew the move to 32 bit was going to cause some conversion problems with my 8 bit libraries, but I was a little surprised at int. I've always assumed that signed and unsigned int were 2 bytes in size. As Frank's link has shown me, int is not 'typed' in stone. Most of my code that I'm converting/re-writing, unfortunately, uses signed int and unsigned int. Fortunately, not a big deal, just another learning experience in the move to Teensy :)

Thanks for the help,
Bruce
 
you can just replace your ints with int16_t or uint16_t, this way they remain the same :)

edit: ...and it will still work for your 8-bit mcu :)
edit2: sometimes, in rare cases,with teensy, int16 is a little bit slower than int32. dunno what gcc exactly does in these cases, until now it was not that important for me to look for the details in the generated assembly. perhaps it adds additional code for overflows
 
Hi Frank,
That's what I'm doing now. My mistake was relying on the use of the fundamental data types and not using those defined in stdint.h. Stupid decision!!!
 
yeah, in cases, where the the size is not important (for example a loop-counter 0..10 or something like that) , use the native int - which, in theory is the fastest type for the cpu.
 
Agreed. Actually, you've just unknowingly answered a mental question of mine. Logically, if long long is 8 bytes, and long is 4 bytes, then int should be 2 bytes, but it's 4; only short is two.. Your comment "native int ..." is the old metaphorical "facepalm". That's why it's 4 bytes. Thanks Frank, now I get it. I may be slow, but I get there eventually;-)
 
brtaylor,
Thank you for sending me to that resource. In reading the page you sent me to, as well as glancing at a few other pages, it seems to be a useful site and I've bookmarked it for a more thorough read.
 
Status
Not open for further replies.
Back
Top