feat: Motorola S-Record and Intel HEX to binary conversion (#257)#633
Open
gradams42 wants to merge 3 commits into
Open
feat: Motorola S-Record and Intel HEX to binary conversion (#257)#633gradams42 wants to merge 3 commits into
gradams42 wants to merge 3 commits into
Conversation
Two bugs in resolve_link() caused a crash when processing software packages that use the common soname symlink pattern (e.g. libhelics.so -> libhelics.so.3 -> libhelics.so.3.5.3): 1. `while current_path.is_symlink:` referenced the bound method as an attribute rather than calling it. A method reference is always truthy, so the loop never terminated based on the symlink check and instead called readlink() on the final regular file, raising OSError: [Errno 22] Invalid argument. 2. `cur_dir = current_path.parent` assigned a Path object back to a variable typed and used as str. On the next loop iteration, `cur_dir[len(common_path):]` raised TypeError because Path does not support string subscripting. Fix: call is_symlink() with parentheses and wrap current_path.parent in str() so cur_dir stays a string throughout the loop.
gradams42
force-pushed
the
feat/srec-hex-conversion
branch
from
June 12, 2026 03:27
f4febbc to
b0ca07d
Compare
I saw that issue llnl#257 (Add ability to convert Motorola S-Record and Intel Hex files into binary files) was being worked on in the upstream branch srec-and-hex-support. After looking at the progress made thus far, I ported the implementation into a new infoextractor plugin (srec_hex.py) and fixed two bugs present in the upstream branch: - ConfigManager reads were evaluated at module import time as global constants, preventing test isolation and conflicting with issue llnl#470. Moved all three config reads inside extract_file_info() so they reflect the current config at call time. - Gap-padding between data records was written as ASCII '0' (b"0") instead of null bytes (b"\x00"), producing incorrect binary output for any file with non-contiguous address ranges. The extractor supports three config options: srec_hex.max_file_size - skip if converted output exceeds this (default 1MB) srec_hex.strip_leading_zeros - trim leading padding before first data address srec_hex.output_path - directory for converted binaries (default: system temp) Testing: Ran the new tests directly to verify SREC and HEX decoding: pytest tests/file_types/test_srec_hex_files.py -v → 2 passed Ran the full test suite to confirm no regressions: pytest tests/ -v → 179 passed, 4 skipped
gradams42
force-pushed
the
feat/srec-hex-conversion
branch
from
June 12, 2026 03:30
1dc64da to
e2ef995
Compare
for more information, see https://pre-commit.ci
🆕 New Folders (1)
🧪 SBOM Results (1/17)
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Issue #257 (Add ability to convert Motorola S-Record and Intel Hex files into binary files) was being worked on in the upstream branch
srec-and-hex-support. After reviewing the progress made, I ported the implementation into a new infoextractor plugin (srec_hex.py) and fixed two bugs present in that branch. I tried to keep as much of the current implementation as possible, in order to align with the current development thought processes.Bug fixes:
ConfigManager at import time —
MAX_FILE_SIZE,STRIP_LEADING_ZEROS, andEXTRACT_DIRwere evaluated as module-level globals at import time, preventing test isolation and conflicting with issue Global settings can influence tests #470. Moved all three reads insideextract_file_info()so they reflect the current config at call time.Incorrect gap-padding — padding between non-contiguous data records was written as ASCII
'0'(b"0") instead of null bytes (b"\x00"), producing incorrect binary output.The extractor respects three config options:
srec_hex.max_file_size— skip conversion if output would exceed this size (default: 1MB)srec_hex.strip_leading_zeros— trim leading zero-padding before the first data addresssrec_hex.output_path— directory to write converted binaries (default: system temp)Testing
Ran the new tests directly to verify SREC and HEX decoding:
Ran the full test suite to confirm no regressions: