Is your feature request related to a problem? Please describe.
open_port/2 supports length-prefixed packets through {packet, N}, but packet-length headers are always big-endian. Erlang processes using a spawned program or an {fd, In, Out} port cannot select little- or native-endian framing.
Callers that use non-big-endian protocols must fall back to {packet, raw} and implement framing themselves. This duplicates framing logic and prevents them from using the port's built-in packet handling.
Describe the solution you'd like
Allow callers to select the endianness of packet-length headers on spawned and file-descriptor ports. Existing {packet, N} behavior must remain compatible.
The capability should support little- and native-endian headers and include documentation and tests for supported packet lengths. Its public API should align with related packet APIs where their abstractions match.
Describe alternatives you've considered
Using {packet, raw} allows callers to implement framing themselves, but duplicates packet parsing for every non-big-endian protocol. Existing endian-aware options for gen_tcp and erlang:decode_packet/3 apply to different transports and do not cover ports created by open_port/2.
Additional context
The directly related prior work is #590, which attempted little-endian packet headers for ports and closed without merging.
Is your feature request related to a problem? Please describe.
open_port/2supports length-prefixed packets through{packet, N}, but packet-length headers are always big-endian. Erlang processes using a spawned program or an{fd, In, Out}port cannot select little- or native-endian framing.Callers that use non-big-endian protocols must fall back to
{packet, raw}and implement framing themselves. This duplicates framing logic and prevents them from using the port's built-in packet handling.Describe the solution you'd like
Allow callers to select the endianness of packet-length headers on spawned and file-descriptor ports. Existing
{packet, N}behavior must remain compatible.The capability should support little- and native-endian headers and include documentation and tests for supported packet lengths. Its public API should align with related packet APIs where their abstractions match.
Describe alternatives you've considered
Using
{packet, raw}allows callers to implement framing themselves, but duplicates packet parsing for every non-big-endian protocol. Existing endian-aware options forgen_tcpanderlang:decode_packet/3apply to different transports and do not cover ports created byopen_port/2.Additional context
The directly related prior work is #590, which attempted little-endian packet headers for ports and closed without merging.