Feed a chunk of bytes, dispatching decoded fields to the bound visitor, and return where the decode stands after them (§5.2.1): DecodeStatus.Complete when they end exactly at a field boundary, DecodeStatus.Incomplete when they end inside a field (a partial varint, an unfinished payload / array, or a still-open nested sequence). Running out of bytes mid-field is not an error — the decode merely suspends until the next chunk, and the caller owns end-of-input.
This call is the only place the answer is. There is no finish / finalize step (§5.2.4) and no status accessor: what this returns, or throws, is the whole of what the stream has to say, so a caller is never one question short after it and never has two answers to reconcile. Feeding an empty chunk re-reads the same value without consuming anything, for a caller that wants the outcome again without holding on to it.
The chunk is borrowed only for the duration of this call (§6.0): once it returns, the caller may reuse, overwrite or free that memory, and the decoded message is unaffected — the decoder retains nothing that points into it.
INVALID travels on the error channel — this port's idiomatic surfacing of
it: malformed bytes throw SofabError (INVALID_MSG) instead of
returning a status, which is why the return type names only the other two.
That verdict is terminal (§5.2.1): the stream latches it, so a caller that
catches the throw and feeds on gets the same error again from every later
call — no further byte is consumed and no visitor method is invoked. A caller
that caught it already holds the verdict, in the code on the error it caught.
A receiver-limit rejection (LIMIT_EXCEEDED, §6.2.1) travels the same
channel — thrown out of the visitor callback that compared the cap — but it
is not the INVALID outcome and never becomes one: the bytes are
well-formed and the same message decodes under a looser cap, so it is a
policy rejection (§6.2.1, §6.3). The two stay distinguishable by their code,
which is what §6.3 requires; §6.3 leaves the surfacing open between "a fourth
decode outcome" and "a terminal failure carrying the LimitExceeded code on
the error channel", and this port takes the second. Terminal is the other
half of that sentence and holds exactly as it does for INVALID: the stream
latches the rejection, so every later call re-throws it under the same code,
consumes no byte and drives no visitor method. It is only on the error
channel — the three-valued outcome has no value for "valid, but more than I am
configured to accept", so there is nothing about it to read back as a status,
and nothing that has to be kept in step with the throw.
Push parser for the SofaBuffers wire format, and the library's only decode surface (§5.3.1).
Bind a Visitor at construction, then feed bytes in chunks of any size with feed: it calls one visitor method per decoded field and resumes cleanly across chunk boundaries. Every
feedreturns the decode outcome for the bytes so far, so no end / finalize call is needed — and there is nothing else to ask:feedis the only way to learn where a stream stands, by what it returns or by what it throws.No receiver limit is configured here, because this codec holds none (§6.2.1). A
max_dyn_*cap is the receiving application's number, stated by generated code, which knows the schema and the target; it is compared inside the visitor's ownarrayBegin/fixlenBegin— raised by this stream at the count or length header, before any payload is delivered and only for a field the visitor reads — and, for a wrapper array'sstring/blobelements, inside theStringSeq/BlobSeqcollector those bounds were passed to. This class used to take aDecodeLimitsand default every absent cap to the format ceiling, which §6.2.1 forbids twice over: a codec must not supply a default for a limit it was not given, and a format ceiling reached because no cap was stated is the format's bound and must not be presented as a receiver cap.Constructing one is the only allocating step (§6.6):
feeditself allocates nothing at all. The one-shot decode is exactly this class fed once.