5.15. APIs (Multiple Languages)

5.15.1. [Major] Using a Listener and a Waitset in the same application may have resulted in the Waitset waking up unexpectedly

In applications where both a Waitset and a Listener are used on the same DataReader, if the application did not provide a Listener upon Entity creation, but later used the DDS_DataReader_set_listener API, the Waitset may have repeatedly woken unexpectedly.

[RTI Issue ID CORE-11125]

5.15.2. [Major] Sentinel constant for “invalid” Time contained unexpected value *

Due to a regression in 7.2.0, the sentinel Time value that indicates an “invalid” timestamp was incorrect and didn’t match the value of an “invalid” SampleInfo::source_timestamp (which can be returned when an instance state is NOT_ALIVE_NO_WRITERS). This made a comparison such as the following to never be true:

if (info.source_timestamp() == Time::invalid()) {} // never true due to this bug

Time::invalid() now contains the expected sentinel value.

[RTI Issue ID CORE-14334]

5.15.3. [Minor] IDL printing of Enum TypeCodes was not standards-compliant

The DDS_TypeCode_to_string API can be used to print a DDS_TypeCode in IDL representation. When used to print enums, TypeCodes were printed in a non-standard format, as follows:

enum MyEnum {
  ZERO = 0,
  ONE = 1
};

The following format is mandated in the OMG ‘Interface Definition Language’ specification, version 4.2:

enum MyEnum {
  @value(0) ZERO,
  @value(1) ONE
};

Now, enums are printed using the @value annotation.

[RTI Issue ID CORE-13956]

5.15.4. [Minor] Extensibility of unions defined within modules incorrectly printed as IDL *

When a union that was defined within a module was printed, the extensibility of that union was printed at the scope of the module, instead of the union.

[RTI Issue ID CORE-13945]

5.15.5. [Minor] Incorrect output when printing a union with an enum discriminator as IDL

The DDS_TypeCode_to_string API allows TypeCodes to be printed as IDL. When printing a union that had an enum as its discriminator, the case labels may have been incorrectly printed, if the enum case labels were not used in the same order in which they were defined in the enum. For example:

enum MyEnum {
  RED,
  GREEN,
  YELLOW
};

union MyUnion switch (MyEnum) {
case YELLOW:
  char x;
case GREEN:
case RED:
  uint32 data;
};

The union would have been printed with incorrect case labels, since the case labels appeared in an order different than the order in which they were defined.

[RTI Issue ID CORE-13941]

5.15.6. [Trivial] First enum label not printed

By default, when printing TypeCodes (using the DDS_TypeCode_to_string APIs), the ordinal values associated with an enum are only printed if they are explicitly provided in the type definition. There was a bug where the first ordinal value was never printed (even if it was explicitly supplied in the type definition).

[RTI Issue ID CORE-14400]

* This bug does not affect you if you are upgrading from 6.1.x or earlier.