DDS-XTypes 1.4b1 RTF Avatar
  1. OMG Issue

DDSXTY14 — Appending to an appendable struct can break XCDR1 deserialization

Open Closed All
  • Key: DDSXTY14-97
  • Status: open   Implementation work Blocked
  • Source: Foxglove Technologies Inc ( Mak Nazecic-Andrlon)
  • Summary:

    The XCDR1 encoding of both final and appendable structs uses PLAIN_CDR encoding. The idea behind appendable structs is that you can append members to them without breaking backward compatibility. However, this is not achievable with PLAIN_CDR encoding. Consider the following IDL (call this version 1):

    @appendable struct A

    { char x; }
    @appendable struct B { char s; A a; char t; }

    And now suppose in version 2 of we append a member to A and keep B the same:

    @appendable struct A { char x; char y; }
    @appendable struct B { char s; A a; char t; }

    Version 2 of B is assignable to version 1 of A, and thus a receiver using the version 1 definitions should successfully deserialize any serialized instance of B of version 2.

    However, this is not possible. Consider this version 3 of the IDL, which is not compatible with version 2, but is compatible with version 1:

    @appendable struct A { char x; }

    @appendable struct B

    { char s; A a; char t; char u; }

    Consider now the objects p = B { s: '1', a: A

    { x: '2' , y: '3' }

    , t: '4' } in version 2 and q = B { s: '1', a: A

    { x: '2' }

    , t: '3' , u: '4' } in version 3. We have p.t = '4' and q.t = '3'.

    For correctness, we need to have both deserialize_1(serialize_2(p)).t = '4' and deserialize_1(serialize_3(q)).t = '3' (where _n is the version of the IDL being used).

    However, both p and q serialize to "1234" under XCDR1. That is, serialize_2(p) = "1234" and serialize_3(q) = "1234".

    Substituting, we thus need to have both deserialize_1("1234").t = '4' and deserialize_1("1234").t = '3', which is impossible because '3' and '4' are distinct.
  • Reported: DDS-XTypes 1.3 — Thu, 10 Jul 2025 05:39 GMT
  • Updated: Mon, 14 Jul 2025 15:04 GMT