nros rmw-cffi
C vtable for plugging a third-party RMW backend into nros
Loading...
Searching...
No Matches
Data Fields
rmw_byte_span_t Struct Reference

#include <rmw_entity.h>

Data Fields

const uint8_t * data
 
size_t len
 

Detailed Description

Global identifier for a publisher — upstream rmw_gid_t, field for field.

Phase 376 W4. Mirrors upstream exactly, including the 24-byte width and the implementation_identifier. The identifier matters MORE here than upstream: nros_rmw_cffi_register_named admits several backends in one image, so two gids are comparable only when it matches.

Comparison is over the whole array, so a producer MUST zero-pad an identifier shorter than 24 bytes rather than leave the tail undefined — otherwise two gids naming the same entity compare unequal on stack garbage.

24, not 16, and that is a discrepancy worth knowing about. Our own MessageInfo::publisher_gid (nros-core, PUBLISHER_GID_SIZE) is 16 bytes, while the Cyclone backend already computes 24-byte gids for the DDS graph (entity_gid_24 in graph.cpp). Under upstream semantics those are the SAME identifier, so a gid obtained from a take cannot today be compared with one from get_gid_for_publisher without a documented mapping — and the narrower one truncates. The ABI takes upstream's width; reconciling MessageInfo is its own change and is NOT done here. Bytes to READ — phase-406 W2.

len is a FACT: how many bytes exist. Nothing is written through this, and const says so — publish handing a backend a mutable pointer is an invitation.

PASSED BY VALUE. Two words, and there is nothing to report back.

Field Documentation

◆ data

const uint8_t* rmw_byte_span_t::data

◆ len

size_t rmw_byte_span_t::len

The documentation for this struct was generated from the following file: