Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
The specification does not define how memberIDs are computed in the case where the @autoid (or @hashid) annotations are used. This is needed for interoperability.
Section 184.108.40.206.1.1 (Member IDs) specifies there are thee ways to set them:
- Automatically following a progression that starts from the most-recently specified member ID.
- Using the @id annotation
- As a "hash" on the member name when @autoid(HASH) is specified
- as a "hash" on a string-parameter when @hashid("string-parameter") is specified
The use of @autoid refers to sub clause 220.127.116.11 in [IDL41]). But there also there is no specification of how the hash should be computed. Only that a "hashing" algorithm should be used.
IDL working group discussed this and the preference was to leave it unspecified in IDL4 and instead put it in XTYPES or whichever specification depends on these IDs.
A proposal would be to use an MD5 (as this is already used for key hashing).
This needs to be done in a platform-independent manner, for example hashing a serialized representation of the string using a pre-specified endianness. Also per section 18.104.22.168.4.3 (Member IDs) the value/range must be representable in 28 bits.
Reported: DDS-XTypes 1.2 — Fri, 7 Apr 2017 00:44 GMT
Updated: Fri, 7 Apr 2017 00:44 GMT