Decode with bounds and application checks

Separate representation checks, incomplete input and application-specific limits.

• Symbolic constants and typedefs declare names but encode no data by themselves. For example const MAX=8 and typedef unsigned int counter; do not add words before a counter value. The formal language is a data description, not executable code. The source’s §§4.17–4.18 and 6 define these rules.
• The second state is a selected LOCAL buffer example for variable opaque data with count 5. Seven received bytes contain the four-byte count plus three payload bytes; the complete encoding needs twelve bytes including padding. Five more bytes are required before this helper returns a value. XDR defines the representation, not TCP delivery, message boundaries or an acknowledgment protocol (§§3,4.10).
• The helper preserves incomplete input with zero consumption, checks its chosen bound before allocation and preserves a coalesced tail after a complete item. These are explicit implementation choices used to teach safe decoding. They do not implement every XDR type, a streaming transport or a general protocol parser (§8).
• Counted bytes61 00 62 represent the three ASCII bytes a,NUL,b; a following zero is padding. The representation can be valid while a C-string API sees only a. Section8 warns about this memory-management hazard. The illustrated application gate rejects embedded NUL under its own string policy; XDR itself does not globally forbid that counted byte. Slash characters can likewise be legal ASCII yet illegal for a particular filename component.
• Section8 advises non-recursive processing or limits on recursive structures to avoid denial of service. A chosen limit of two nodes stops a third node; two is an example, not an RFC-mandated constant. Resource limits remain necessary even with legal optional-data encodings. Protocols carrying XDR must provide any required security services; XDR does not supply encryption, identity or permission checks.