Closed reubeno closed 4 years ago
Thanks! Your PR has not been forgotten :) Yet it must wait for the nearest weekend to be processed.
The change is nice and well described. The only thing missing is at least one unit test - please take a look at other tests in the project (use second solution file for that). If for some reason you can't use the binary in which you encountered described problem (e.g. due to copyrights), maybe alter a "normal" binary in hex editor?
As you wrote, it would be nice to have some kind of fault logging mechanism. Another nice feature would be to have a flag set in ELF ctor, telling whether to ignore such errors or fail at them. But this will probably be introduced in the future, so no need to take it into account within this pull request.
Thanks for the feedback, @konrad-kruczynski . It's taken me a while to get back to this, but I've followed your suggestion and added a test case with a small binary; without the fix in this PR, the test fails -- and with it, it passes. Any and all feedback welcome!
Finally had some time to look at this. Looks good to me! Now I only need some release-related changes:
ELFSharp.csproj
and bump informational, package and file version to 2.2.0 (or 2.2.0.0 for file), add yourself to the list of authors and describe your change in package release notes;README
.Once again thanks for the contribution.
All done! Let me know if you see anything else you'd like me to update.
Will this somehow automatically result in an updated package posted to NuGet, or is that a manual step that you or one of the other project maintainers takes care of?
Great! I'm merging it.
I've come across binaries whose note sections contain data that doesn't match the format expected by ElfSharp. This change ignores such data, rather than throwing on parse of the binary.
Any and all feedback very much welcome -- in particular, I wasn't sure if there was a recommended way to non-fatally warn or otherwise log information about the unexpected sizes.