lasp / lasp/space_packet_parser
Bare UTF-16 / UTF-32 string encodings ignore the XTCE byteOrder attribute
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 39
- Forks
- 15
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 12
Description
Follow-up from review of #291. Pre-existing on main; not introduced by that PR.
StringDataEncoding._supported_encodings includes the bare UTF-16 and UTF-32 spellings alongside the explicitly-endian UTF-16BE / UTF-16LE / UTF-32BE / UTF-32LE. For the bare spellings, Python's codec decides endianness from a byte-order mark, and defaults to little-endian when there is no BOM.
XTCE carries endianness in the byteOrder attribute instead, and packet buffers do not carry a BOM. So a big-endian document that declares encoding="UTF-16" with byteOrder="mostSignificantByteFirst" decodes little-endian — the byteOrder attribute is accepted and then ignored.
from space_packet_parser.xtce import encodings
# byteOrder says big-endian; the bare UTF-16 codec decodes little-endian anyway
enc = encodings.StringDataEncoding(
encoding="UTF-16",
byte_order="mostSignificantByteFirst",
fixed_raw_length=32,
)
Fix
Resolve byte_order to an explicit BE/LE codec at construction time when the declared encoding is a bare UTF-16 / UTF-32, so the attribute is honored.
This changes decoded values for any existing definition using a bare spelling, which is why it is filed separately rather than folded into #291.
Note on a related review claim
A review comment on #291 suggested that constructing a bare-codec encoding raises UnicodeDecodeError before the terminator search runs. That is not the case and was verified against the branch — b"\x00\x00".decode("UTF-16") is "\x00", a single character, which passes the constructor's single-character terminator check, and the relevant tests pass. The endianness gap above is the real residual issue.
🤖 Generated with Claude Code
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with encodings.StringDataEncoding and its _supported_encodings handling for bare UTF-16 and UTF-32. Resolve the declared byte_order to the appropriate explicit-endian codec and add or update coverage for big- and little-endian bare encodings; done means the XTCE byteOrder attribute controls decoding without a BOM.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100