Go Down

Topic: Strange array index in Print::printNumber (Read 589 times) previous topic - next topic

fat16lib

Why is the array index for 'buf' in Print::printNumber an unsigned long?

I change
Code: [Select]

 unsigned long i = 0;

To
Code: [Select]

 uint8_t i = 0;

And it seems to work and saves about 60 byte.

PaulS

What happens, with your modification, if the array being printed contains 300 characters?

fat16lib

Can't happen since buf has dimension 32.  
Code: [Select]

 unsigned char buf[8 * sizeof(long)]; // Assumes 8-bit chars.

This is the max number of characters required to print an unsigned long in binary/ base 2.

The while loop in printNumber limits i to 32 or less.

leppie

If that is only a local variable, the optimizer normally does a good job of 'squashing' it (with int normally).  Maybe it sucks for unsigned long :)

fat16lib

#4
Jun 25, 2010, 02:36 pm Last Edit: Jun 26, 2010, 04:02 am by fat16lib Reason: 1
I would have expected it to optimize also but it doesn't.  My guess was that the while loop fools the compiler since that is what limits the size of i but who knows.

Anyhow unsigned long makes Print about 60 bytes larger.

Actually the compiler can't optimize because there is sort of a bug in Print.  If you call print with base == 1 it will zero most of memory.  If you change the unsigned long to uint8_t it will not behave the same.  It will loop zeroing 256 bytes of memory.

Go Up