[Question] Why is len(binfile) != len(binfile.as_binary())?

[ahogen]

I haven't looked into this too deeply, but just thought I'd ask. How come the length of the binfile object is not equal to the length of the bytes returned by binfile.as_binary()?

For example, if you added this statement to the regression test code, the test will fail.

--- a/tests/test_bincopy.py
+++ b/tests/test_bincopy.py
@@ -397,6 +397,7 @@ class BinCopyTest(unittest.TestCase):
         self.assertEqual(binfile.minimum_address, 0)
         self.assertEqual(binfile.maximum_address, 184)
         self.assertEqual(len(binfile), 170)
+        self.assertEqual(len(binfile), len(binfile.as_binary()))

         # Dump with start address beyond end of binary.
         self.assertEqual(binfile.as_binary(minimum_address=512), b'')

Could you explain the difference between the two?

Thanks!

[eerimoq]

len(binflie) is the sum of all segments' lengths.

len(binfile.as_binary() is the binary minimum address subtracted from the maximum address. So this includes padding between segments.

So if you have a file with two segments, say addresses 0-10 and 90-100, len(binfile) returns 20, while len(binfile.as_binary() returns 100.

I have absolutely no idea if this behavior is good, but that's how it works.

[ahogen]

Ah! Okay, that is good to know. I can certainly understand the reasoning there.

I guess maybe the padding=None default argument of as_binary() might have been throwing me off. In terms of the English language, that obviously looks like "no padding will be added between segments". Which obviously does not make sense when generating a binary blob... you need padding. So the behavior makes sense, but the "api" wording was throwing me off.

Anyhow, thanks for the clarification.

And thanks for the library! Been getting a some good use out of it! Saved me a lot of headache as I have a need to read, modify, and write compiled ihex/binaries.

Cheers!

[eerimoq]

I clarified that giving padding as None means pad with 0xff.