Get_first_emtpy_address - ALDB entries that lack an address should be ignored #44
Conversation
… ignored When a link is added by MH, the record is first put into the aldb hash without an address as a sort of placeholder. Get_first_empty_address is then called to find an empty location in which to put the record. Get_first_empty_address then loops through the aldb hash looking for the lowest used address. In looping, it will come across the record that was just described, which lacks an address. The subroutine then hexes the address, or lack there of, which for the placeholder results in an address of 0. The subroutine then improperly interprets this, the 0 result, as the lowest address. This results in bizarre situations. In the most benign situation, the subroutine reports that it cannot find an unused address which results in an error requesting a re-scan of the device (this was happening to me a lot). In the more dangerous situation, the subroutine may report a used address as being empty which results in that address being over written. This patch prevents an address of 0 from being used as a low address, effectively ignoring the placeholder added above and preventing the issues described.
|
This simple fix really should be merged in. Without it, sync_links does a whole bunch of odd stuff. |
Get_first_emtpy_address - ALDB entries that lack an address should be ignored
|
Kevin, there is an additional condition that is not handled by the existing code or your enhancement. If the hash contains an empty entry (because of another bug somewhere else) the code will still return zero. I had such a bug in the i2 code that I subsequently fixed but prior to that I rewrote get_first_empty_address(). The routine was just overly complex in my mind. Take a look at the changes that I made in the i2 version and see if you think those changes are good for the i1 version as well. Eventually I would like to merge as much i1 and i2 code as possible. This is a routine that we should be able to share. |
|
I may have caught it already. There was a one line merge done about 2 On Fri, Feb 1, 2013 at 6:30 PM, Michael Stovenour
|
When a link is added by MH, the record is first put into the aldb hash without an address as a sort of placeholder. Get_first_empty_address is then called to find an empty location in which to put the record.
Get_first_empty_address then loops through the aldb hash looking for the lowest used address. In looping, it will come across the record that was just described, which lacks an address. The subroutine then hexes the address, or lack there of, which for the placeholder results in an address of 0. The subroutine then improperly interprets this, the 0 result, as the lowest address.
This results in bizarre situations. In the most benign situation, the subroutine reports that it cannot find an unused address which results in an error requesting a re-scan of the device (this was happening to me a lot). In the more dangerous situation, the subroutine may report a used address as being empty which results in that address being over written.
This patch prevents an address of 0 from being used as a low address, effectively ignoring the placeholder added above and preventing the issues described. This is a further patch to the empty_aldb patch that I previously submitted.