be quicker about determining erased byte pattern when flashing

[gtalusan]

Not a bug, just a slight improvement.

[texane]

Did you test it ? index is an unsigned int, always >= 0 ... so the terminal condition of the for loop looks suspicious to me ... ?

[gtalusan]

Yup. It behaves the same as previously but with less iterations. The index is decrementing so it'll always hit 0 or break out if the byte being inspected isn't erased_pattern.

If the break condition were just true since index is an unsigned, then we'd get wrap around and an input that was full of 0xff or whatever erased_pattern is, would cause an infinite loop.

[texane]

I understand what it does. But when index hits 0, the for loop does not exit, so
index will wrap to (unsigned int)-1 = 0xffffffff, and invalid memory reference may
occur. That is what is not correct, not the goal itself.

ps: thanks for your commits by the way !

[gtalusan]

Ah, I see!

Okay, updated. Here I tested with a bin full of 0xff's and made st_write_flash go through the step of erasing the flash if mf.len == num_empty. Previously the code would do nothing.

The unsigned confusion should be gone too - the precondition is now to check if we've seen as many empty bytes as there are bytes mapped in memory.

There's a bit of pollution of st_write_flash's function declaration, but that's because the function does a bit much.

[texane]

Thanks. I rewrite the code a little bit, hope you do not mind.

[gtalusan]

Thanks!

On Feb 27, 2016, at 1:18 PM, texane notifications@github.com wrote:

Thanks. I rewrite the code a little bit, hope you do not mind.

―
Reply to this email directly or view it on GitHub.