Requested bytes versus accepted bytes

What this concept is

An I/O operation needs an explicit progress contract. Requested length is an intention; the returned count reports accepted progress. A helper can stop after a failure while still having changed the destination.

Why it matters here

Module 2 taught failure-preserving local allocation. Output is different: an accepted prefix generally cannot be rolled back. The caller needs the prefix length to decide whether and how recovery is possible.

Concrete example

To send bytes abcdefg, a writer accepts abc, then de, then fails. The result reports five accepted bytes and an error. Restarting at a duplicates the prefix. Continuing at f is valid only if the destination contract still represents the same stream and state. A new connection is not automatically a continuation.

Common confusion / misconception

“Write all” is not a transaction and does not mean durable storage or remote application acknowledgment. Identical status codes with different progress counts are different recovery situations.

How to use it

Maintain the invariant that accepted bytes are exactly the input prefix of the reported length. Advance the data pointer by the returned positive count, never the request size. Retain the error and progress together. Check count validity before updating arithmetic. Do not replay external effects merely because a local function returned failure.

Check yourself

Which suffix remains after counts 3 and 2 for a seven-byte input? Why can a caller not safely retry the complete payload after a partial error?

Mini drill or application

Predict each callback argument for chunk sizes 3, 2 and 2. Then inject a failure after byte 5 and compare actual output with the predicted prefix.

Read this only if stuck

The C Programming Language chapter 8 and Linux write(2) for return-value semantics. The lab’s bounded callback policy is documented separately.