Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

nvx-rs: share one byte-level EXEC and MAPS decoder between the host and the guest

Open
  • Is something wrong?
#581 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
backend

Research direction

The duplicated logic sits in nvx::protocol: compare decode_exec_payload and decode_maps_payload with decode_guest_exec_payload and decode_guest_maps_payload to map the shared framing, flags, and length checks. Keep the host's inherit_default_env rule and the guest's separate rule explicit, and check the result against the C agent parity fixtures that #358 adds. Done means one structural parser feeding both decoders, with the host API, its diagnostics, and guest acceptance unchanged. The issue says to wait until #358 is finished, so do not start before then.

Written by the indexing model from the issue text.

Description

Summary

nvx::protocol decodes the NVXC EXEC and MAPS payloads twice. decode_exec_payload and decode_maps_payload produce the host's UTF-8 types, and decode_guest_exec_payload and decode_guest_maps_payload, which #531 adds, produce the guest's byte strings. Each pair repeats the framing, flags, lengths, and field validation, so a later format or validation change can update one decoder and leave the other behind.

Found in the #531 review. #531 keeps a faithful port of the C agent, so this waits until the #358 series is done.

Proposal

Share the byte-oriented structural parsing, and keep the host's UTF-8 types behind conversions:

  • Keep the public host API and its diagnostics, and keep accepting non-UTF-8 guest arguments, paths, and environment entries.
  • Make intentional host and guest differences explicit rather than substituting one type for the other. For example, the two inherit_default_env fields differ when no explicit environment is supplied: the host's is true (flags & EXEC_ENVIRONMENT_PRESENT == 0 || flags & EXEC_INHERIT_DEFAULT_ENV != 0), and the guest's follows EXEC_INHERIT_DEFAULT_ENV alone.

#537 and #545 can then build on one parsing implementation rather than another pair of codecs.

Tasks

  • Share the structural parsing of EXEC and MAPS between the host and guest decoders, with the host API, its diagnostics, and the guest's acceptance unchanged.
  • Check the shared decoder against the C agent's parity fixtures, which #358 checks in before it removes the C agent. Their expected outcomes must not come from the new decoder.
Dominant language
Python
Stars
408
Forks
28
Avg merge
13h 18m
Merged PRs (30d)
292

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/nvx

All issues in microsoft/nvx

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.