Zephyr OS LwM2M Resource Buffers: Distinguish Capacity from Current Data Length

Registering a resource buffer and writing a resource value are different operations. In Zephyr OS v4.4.0, a buffer registration associates a pointer, capacity, existing-data length and flags with a resource instance. It does not create an independent copy of the application's bytes.

When a remote reader sees a truncated value or stale trailing data, inspect that registration before blaming transport decoding. The important comparison is between allocated capacity, bytes actually initialized and the length currently advertised by the resource. This is a source-based review, not an executed device test.

Give the two lengths different names

The versioned LwM2M interface defines buffer_len as buffer length and data_len as the length of existing data. It also provides a getter for those fields and a setter for the current data length after a caller directly changes the retrieved buffer.

For a hypothetical opaque resource, a 128-byte allocation might initially contain a valid 20-byte record. Registering 128 as both lengths would claim that the entire allocation contains current data. Registering 20 as capacity would instead describe less storage than the application actually reserved. Neither value should be selected just because it is the convenient sizeof expression at the call site.

Keep this example limited to opaque bytes. String and fixed-width resources have their own representation rules; a string's terminator and a numeric resource's width cannot be inferred from this opaque-record example.

Registration stores metadata, not a validated copy

The tagged registry implementation resolves the resource instance and assigns the pointer, lengths and flags in lwm2m_set_res_buf(). That setter does not compare the supplied data length against capacity before storing them. A successful registration is therefore not a substitute for the application's bounds check.

The same implementation makes lwm2m_set_res_data_len() retrieve the existing registration and reuse the buffer setter with a replacement length. It does not copy new bytes into the resource or invoke the typed-value setter's validation and post-write path.

Before registration, verify that the pointer refers to storage with the required lifetime and that the current length describes valid initialized bytes within that storage. Do not register a temporary local array that disappears when the setup function returns. A pointer remaining non-null does not keep its former allocation alive.

Decide how updates become visible

Suppose the hypothetical record shrinks from 20 bytes to eight. Updating only the first eight bytes leaves the prior advertised length unchanged unless the application follows the required length-update path. Updating only the metadata, before preparing those eight bytes, can instead expose a description that does not yet match the data.

Choose an update method with explicit synchronization between writers and readers. Do not infer that the registry's internal locking makes arbitrary application writes through a previously retrieved pointer atomic. The copy operation and the metadata update need a coherent application policy, or the product should use the appropriate resource-value API and its documented constraints.

This distinction also matters for callbacks. A direct memory edit followed by a length adjustment should not be treated as evidence that the normal value-write validation or post-write hooks executed. If the product depends on such processing, trace the actual update path rather than relying on similarly named setters.

Check a small set of revealing cases

In a disposable test, inspect pointer, capacity and current length after initial registration, after growth within capacity and after shrinking a value. Use a recognizable unused-tail pattern to reveal accidental exposure of bytes outside the current record. Reject an oversized proposed length in application logic before passing it onward.

Finally, verify the remote representation through the resource's declared type and the chosen update API. Correct transport delivery cannot repair incorrect local length metadata. Keeping capacity, content and advertised length consistent is the first step toward diagnosing the result meaningfully.