`payloadMarker` is initialized to `0x00` instead of RFC 7252's `0xFF`

[ndss27]

Summary

The payload marker that separates options from payload in a serialized CoAP message must be 0xFF (RFC 7252 §3). The struct declares the correct default, but the constructor's member-initializer list value-initializes the field to 0x00, which overrides the in-class default. Serialized packets therefore use 0x00 as the marker, and a conforming parser stops reading at the wrong place.

Root cause

// include/packet.h:233  — correct in-class default
const std::uint8_t payloadMarker = 0xFF;

// include/packet.h:236  — constructor RE-initializes it to 0
message_s():headerInfo{0}, code(), messageId(0), token{0},
            options(), payloadMarker(), payloadOffset(0), payload() {}
//                       ^^^^^^^^^^^^^^^ value-initializes to 0x00, overriding 0xFF

When a member is named in a constructor's mem-init list, that initializer wins over the in-class default. payloadMarker() value-initializes the uint8_t to 0, so every message_s built through this constructor has payloadMarker == 0x00.

Steps to reproduce

packet p;
/* set a payload on p, then serialize */
std::vector<uint8_t> buf = /* p.serialize(...) */;
// EXPECTED: buf contains 0xFF immediately before the payload (RFC 7252 §3)
// ACTUAL:   the marker byte is 0x00

(Equivalently, assert that a freshly constructed message_s has payloadMarker == 0xFF; it is 0x00.)

Expected vs. actual

• Expected: payloadMarker == 0xFF.
• Actual: payloadMarker == 0x00; serialized messages use the wrong marker and interoperating parsers misframe the payload.

Suggested fix

Remove payloadMarker() from the constructor's mem-init list (let the in-class = 0xFF default apply), or initialize it explicitly:

message_s():headerInfo{0}, code(), messageId(0), token{0},
            options(), payloadMarker(0xFF), payloadOffset(0), payload() {}