Partial writes: advance the buffer offset instead of resending the full payload

What it is

The Linux write manual states that a successful call can transfer fewer bytes than requested. Its return value tells the caller how much progress occurred, and a later call may transfer more or fail. Success therefore does not imply that an entire application buffer was consumed, nor does it establish durable storage. Linux write manual

Why it matters

An agent may retry the original buffer after a short write, duplicating its already-sent prefix. The key state is the unsent suffix. Make that state explicit across ordinary progress, interruption, backpressure and terminal failure instead of translating all outcomes into a generic retry.

How to apply

• Track the current offset and total intended byte count. On a positive return, advance by exactly the reported amount and offer only the remaining suffix next time.
• Distinguish a terminal error from a would-block result on a nonblocking descriptor. Preserve the pending buffer and resume through the chosen readiness mechanism rather than busy-looping.
• Give zero progress an explicit policy so a loop cannot spin indefinitely. Keep deadlines and cancellation observable while output remains pending.
• Propose a controlled writer fixture that accepts only part of each buffer, then injects backpressure or a failure. Assert the exact resulting byte sequence, not merely the count of calls.
• For a higher-level protocol, define what a partially transmitted message means after failure. Do not automatically replay it on a new connection without that protocol's recovery rule.

Pitfalls

A write loop solves local byte accounting, not exactly-once application delivery. File durability and peer acknowledgement are separate contracts. Also check how the application handles a closed pipe or socket, including relevant signal behavior. No system-call fault-injection run is claimed here; the fixture is a proposed regression design for the wrapper being changed.