false data in output
afk-olkie opened this issue · comments
Originating from discussion in issue #3 .
Address space: let's call from 0x00 to 0xFF sector 1, and 0x0100 to 0x01FF sector 2.
In this pretend scenario, we are controlling a burrito cooking device. Sector 1 details how long to cook the burrito at various different stages for perfection. Sector 2 details which oven to use.
While acquiring the hex file, a hungry person makes a mistake and only extracts sector 2. The source hex file is then fed to this intel-hex lib and it outputs 0xFF for all of sector 1. Now recognize that sector 1 data was never in the source hex file. The burrito cooker depending on intel-hex lib was expecting 512 bytes to be output and that is what it got - it gets zero indication that something abnormal happened.
The result of course is that all the burritos are burning and being cooked way too long (large unsigned cooking times)! A sad day :(
This behavior from a parser (whose job it is to tell you what is in the source file) is counter intuitive and goes against all other intel hex parsers that I've seen on github. At the end of the day, putting a note in the readme about this lib's design choice would help save many a burrito. It's not exactly a bad design choice, but it is very unexpected and should be noted. Thanks!
Who doesn't love burritos? It is quite a sad day indeed when one is burned.
I'll update the README accordingly, although it is rather clear in the code comments that 0xFF is used as padding where data is missing due to address offsets, etc.