Zephyr OS JSON Object Parsing: Check the Decoded-Field Bitmap Before Applying Configuration

A nonnegative result from json_obj_parse does not mean that every field your application requires was present. In Zephyr OS, the result identifies which descriptor entries were decoded. Treating that value as an ordinary zero-success status can reject valid input or accept an incomplete configuration, depending on the surrounding condition.

This article reviews Zephyr v4.4.0 object parsing and proposes an application acceptance pattern. It is not a claim that a particular configuration endpoint was tested or secured. Authentication, authorization and transport protection remain separate requirements for any remotely changeable product setting.

Decode the return value in two stages

The versioned JSON API header specifies a negative error result and a successful bitmap indexed by descriptor position. A set bit identifies a decoded field; it does not certify the application's value constraints. The descriptor length is also bounded by the API contract, so use a sufficiently wide result and mask type rather than narrowing the return to a small status variable.

First test for a negative value. Only then interpret the result as a presence mask. Build a required-field mask from the descriptor entries that the current operation requires, and check that all those bits are present. Optional fields can remain absent without making the object invalid, provided their behavior is explicitly defined.

Do not use a test that requires the return value to equal zero. A valid object with decoded fields normally sets bits. Equally, a test for merely nonnegative success cannot establish that a required device identifier or operating parameter was supplied.

Parse into a candidate, then validate it

The tagged parser implementation writes matched fields while walking the object and builds the bitmap along that path. It can encounter a later decoding error after earlier fields have been written. Therefore an application should not parse directly into live configuration and assume failure leaves that configuration unchanged.

Use a separate candidate object. Initialize its optional values according to the operation's rules, parse into it, verify the required mask, then validate individual ranges and relationships. Publish or apply the candidate only after the whole acceptance path succeeds. This is an application design recommendation, not a transactional guarantee supplied by the parser.

A hypothetical sampling configuration might require a channel identifier and interval while permitting an optional label. Receiving only a valid interval should not silently preserve a channel identifier left in reused scratch memory. A replacement operation can reject the missing channel; a patch operation can deliberately retain the existing channel. Those are different endpoint contracts and should use correspondingly different required masks and initialization policies.

Keep descriptor order and validation together

The bitmap positions follow descriptor order, not JSON text order. Reordering descriptor entries without updating a separately maintained numeric mask can change which fields the application considers mandatory. Give the positions named constants or derive the mask alongside the descriptor definition, and review both in the same change.

A positive presence result also says nothing about semantic compatibility. A supported integer may still exceed the device's permitted interval, and two individually legal fields may describe an impossible combination. Keep semantic validation after presence checking so diagnostics can distinguish a missing field from an invalid supplied value.

Do not infer a strict unknown-field or duplicate-key rejection policy from the presence bitmap. If the endpoint requires such a policy, assess the parser behavior and provide a deliberately verified enforcement layer rather than claiming the mask already implements one.

Test missing and partially decoded input

A proposed regression set includes a complete valid object, each required field omitted in turn, an optional field omitted, an invalid value after an earlier valid field, and a descriptor-order change. For every rejected input, verify that the live configuration remains unchanged. For accepted input, inspect the resulting values rather than only the parser status.

The important boundary is between decoding and application acceptance. The bitmap answers which fields were decoded. Your endpoint still decides whether that set and those values form a complete, permitted operation.