DDSXTY_ — Object assignability rules should be more resilient

Source:

RTI (Mr. Alejandro de Campos, alejandro@rti.com)

Summary:

A small object-level assignability problem within a complex sample can result in an entire sample being discarded. For example, a string whose length is greater than the bound of a string it’s being assigned into must be discarded. A sequence with an unassignable member must be discarded. A structure with an unassignable member must be discarded. As a result, a small issue deep within a structure could cause a whole sample to be discarded. For example, an issue within a TypeObject could result in an entire built-in topic data sample being discarded and consequently a loss of discovery information.

Discussion:

If we attempt to prevent any possible semantic problem that could arise from partial samples, we will have to keep the existing draconian rules, which can have bigger impacts, as described above. Therefore, the rules should seek to be more lenient and allow type-aware code “above” the assignability algorithm to detect semantic problems.

Proposed Resolution:

The following are the cases identified in the specification in which individual objects may be unassignable:

· Strings that are too long: No change. Strings are a basic type, and truncation can generally not be easily detected by applications.

· Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.

· Sequences that are too long or contain unassignable elements: Discard only the offending elements, “left-shifting” subsequent elements and reducing the length as necessary.

· Maps that are too long or contain unassignable elements: No change. Map entries are not logically ordered, so elements may not be discarded in a stable fashion.

· Enumeration with unrecognized value: No change.

· Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.

· Structure with a “must understand” member not present in the destination type: No change—otherwise, the union would be malformed.

Add the following new rules:

· Structure with an unassignable non-optional member: The entire structure is considered unassignable. (This behavior was previously underspecified.)

· Structure with an unassignable option member: The member takes no value. The rest of the structure can theoretically be retained.

The following are the cases identified in the specification in which individual objects may be unassignable along with the changes to be made, if any:
• Strings that are too long: If the bound of a string increases, the string is unassignable. Strings are a basic type, and truncation can generally not be easily detected by applications.
• Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.
• Sequences that are too long or contain unassignable elements: If the bound of a sequence increases, or an element is unassignable, the whole sequence is unassignable. Applications have little ability to detect or mitigate sequence truncation, so automatic truncation is undesirable.
• Maps that are too long or contain unassignable elements: If the bound of a map increases, or an element is unassignable, the whole map is unassignable. Applications have little ability to detect or mitigate map truncation, so automatic truncation is undesirable.
• Enumeration with unrecognized value: No change.
• Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.
• Structure with a “must understand” member not present in the destination type: No change—otherwise, the structure would be malformed.
Add the following new rules for structures, which cover behavior that was previously underspecified:
• An unassignable non-optional member: The entire structure is considered unassignable.
• An unassignable optional member: The member takes no value. The rest of the structure can be retained.
• Mismatched “optional” attribute in a final or extensible structure: The types are not assignable. This restriction is necessary because of the header that precedes such members.