This change adds an early test to see: if there is no 'user_data' (size 0) to parse a type hash, then immediately return OK with a zero-init typehash struct. This avoids executing the rest of the function which would return the same end result.
Topics without user_data can appear when ROS2 apps are run on networks that also carry non-ROS2 DDS traffic.
ROS2 uses the user_data portion of the [Pub|Sub]BuiltinTopicData to carry a "typehash=xxx..." string, but non-ROS2 DDS apps are less likely to use this field, resulting in a 0-length buffer of user_data which is passed to parse_type_hash_from_user_data(). This change detects this condition early, and should have no effect on regular ROS2 topics that use the user_data field.
Tested against rmw connextdds, fastrtps_cpp, cyclonedds_cpp on Iron and Jazzy. Code in Rolling is the same as in these versions.
This change adds an early test to see: if there is no 'user_data' (size 0) to parse a type hash, then immediately return OK with a zero-init typehash struct. This avoids executing the rest of the function which would return the same end result.
Topics without user_data can appear when ROS2 apps are run on networks that also carry non-ROS2 DDS traffic. ROS2 uses the user_data portion of the [Pub|Sub]BuiltinTopicData to carry a "typehash=xxx..." string, but non-ROS2 DDS apps are less likely to use this field, resulting in a 0-length buffer of user_data which is passed to parse_type_hash_from_user_data(). This change detects this condition early, and should have no effect on regular ROS2 topics that use the user_data field.
Tested against rmw connextdds, fastrtps_cpp, cyclonedds_cpp on Iron and Jazzy. Code in Rolling is the same as in these versions.