5.2.24. Other

5.2.24.1. [Critical] Possible Connext validation error while using a valid license

Some valid licenses may have failed Connext license validation.

[RTI Issue ID CORE-15738]

5.2.24.2. [Critical] Data races on architectures with weak memory models

On systems with weak memory architectures, such as Arm® and PowerPC®, data races could have led to undefined behavior or crashes in various Connext components.

[RTI Issue ID CORE-15638]

5.2.24.3. [Major] DomainParticipantFactoryQos could not be retrieved from QosProvider

There was no way to retrieve the DomainParticipantFactoryQos from the QosProvider. This functionality has now been added to the language bindings that did not previously support it: Modern C++, C#, and Python.

Modern C++:

QosProvider qos_provider(user_qos_profiles_uri);
DomainParticipantFactoryQos dpf_qos = qos_provider->participant_factory_qos();
// or qos_provider.extensions().participant_factory_qos();

C#:

QosProvider qosProvider = new QosProvider(userQosProfilesUri);
DomainParticipantFactoryQos dpfQos = qosProvider.GetDomainParticipantFactoryQos();

Python:

qos_provider = dds.QosProvider(user_qos_profiles_uri)
dpf_qos = qos_provider.participant_factory_qos

[RTI Issue ID CORE-6845]

5.2.24.4. [Major] Incorrect hexadecimal formatting for uint8 and octet

Hexadecimal values in generated IDL were printed with an incorrect format (e.g., <5a>). The output has been updated to conform to the OMG Interface Definition Language™ specification, version 4.2, which requires that hexadecimal values start with the “0x” prefix (e.g., 0x5a). This change ensures better compatibility and adherence to standards.

[RTI Issue ID CORE-15797]

5.2.24.5. [Major] Printing to XML missed quotes for external union members

When printing a union with @external members into XML format, the external attribute was missing quotes (e.g., external=true instead of external="true"), resulting in malformed XML that could not be parsed.

[RTI Issue ID CORE-15934]

5.2.24.6. [Major] Printing an IDL or XML enum with a default literal produced incorrect output

When printing an IDL or XML enum that included the @default_literal annotation in one of its enumerators, the output omitted this annotation. As a result, the generated type differed from the original definition.

[RTI Issue ID CORE-15931]

5.2.24.7. [Major] Printing an enum default literal printed the ordinal value instead of enumerator name

When printing in XML or IDL format, default values for enum types were incorrectly represented using the numeric ordinal value (e.g., 1) instead of the enumerator name (e.g., BLUE_1). This resulted in invalid XML and IDL output.

Given this valid IDL:

enum ColorV1 {
    RED_1,
    @default_literal BLUE_1
};
typedef ColorV1 ColorV1Typedef;

struct ColorStructV1 {
    @key ColorV1Typedef color;
};

When printing the previous types, the resulting IDL and XML were:

// Idl
enum ColorV1 {
    @value(0) RED_1,
    @value(1) BLUE_1
};
@default(1) typedef ColorV1 ColorV1Typedef;

struct ColorStructV1 {
    @default(1) @key ColorV1Typedef color;
};

// Xml
<enum name="ColorV1">
    <enumerator name="RED_1" value="0"/>
    <enumerator name="BLUE_1" value="1"/>
</enum>

<typedef default="1" type="nonBasic" nonBasicTypeName="ColorV1" name="ColorV1Typedef"/>

<struct name="ColorStructV1">
    <member name="color" default="1" key="true" type="nonBasic" nonBasicTypeName="ColorV1Typedef"/>
</struct>

This output is invalid, because the XML parser expects the enumerator name (BLUE_1) in the default attribute, not its numeric value.

The output logic has been updated so that when a default value refers to an enum literal, the enumerator name is printed in the XML and IDL representations.

[RTI Issue ID CORE-15930]

5.2.24.8. [Major] XML parser rejected external members with ranges excluding zero

The XML type parser failed to correctly handle external members with a specified min and max range that did not include 0, even though external members are not required to have a default value. This check caused the XML parser to reject otherwise valid type definitions.

Given this XML type definition:

<struct name="MyStruct" extensibility="final">
    <member name="myFloat" external="true" type="float32" min="10" max="11"/>
</struct>

Loading this type using the QosProvider would result in a failure, with the following error:

DDS_XMLTypeCode_getAnnotationParameterValues:Parse error at line 7: annotation values are inconsistent. You must have min <= default <= max. If min or max is specified and min > 0 or max < 0, you must specify the default.

The validation logic has been updated, and now you can load external members with a min and max range that does not include 0.

[RTI Issue ID CORE-15929]

5.2.24.9. [Major] Incorrect string representation of union DynamicType with arrays of sequences

When printing (either in IDL or XML format) a union containing arrays of sequences, the array dimensions were missing from the output. This led to inaccurate or incomplete type representations.

Given the following IDL:

union ArraysOfSequencesUnion switch(long) {
case 0:
    sequence<short,2> myShortSequenceArray[2];
}

The previous (incorrect) string representations were:

// Idl
union ArraysOfSequencesUnion switch(long) {
    case 0:
        sequence<short,2> myShortSequenceArray;
}
// Xml
<union name="ArraysOfSequencesUnion">
    <discriminator type="int32"/>
    <case>
    <caseDiscriminator value="0"/>
        <member name="myShortSequenceArray" type="int16" sequenceMaxLength="2"/>
    </case>
</union>

As shown, the array dimensions ([2]) were omitted from both outputs. The string representations now correctly include the array dimensions:

// Idl
union ArraysOfSequencesUnion switch(long) {
    case 0:
        sequence<short,2> myShortSequenceArray[2];
}
// Xml
<union name="ArraysOfSequencesUnion">
    <discriminator type="int32"/>
    <case>
    <caseDiscriminator value="0"/>
        <member name="myShortSequenceArray" type="int16" sequenceMaxLength="2" arrayDimensions="2"/>
    </case>
</union>

[RTI Issue ID CORE-15928]

5.2.24.10. [Major] Error parsing an XML with an external typedef

If you tried to load the following XML:

<typedef type="nonBasic" nonBasicTypeName="MyStruct" name="MyStructTypedef" external="true"/>

It complained with the following error: RTIXMLParser_validateOnStartTag:Parse error at line 37: Unexpected attribute 'external'. The above XML is now correctly parsed.

[RTI Issue ID CORE-15921]

5.2.24.11. [Major] Invalid escaping of special characters in default strings for XML and IDL output

When converting a DynamicType to a string in XML or IDL format, special characters in default string values (such as “, &, <, and >) were not properly escaped. This led to invalid XML and IDL outputs, breaking compatibility with parsers and tools—particularly during code generation workflows.

Default string values are now properly escaped according to the XML and IDL specifications:

[RTI Issue ID CORE-15886]

5.2.24.12. [Major] DynamicType with default string value incorrectly formatted for XML format

When converting a DynamicType to a string in XML format, if the DynamicType contained a default string, the output was previously default=""default String"". It now correctly renders as default="default String".

[RTI Issue ID CORE-15847]

5.2.24.13. [Minor] Multiple attachments of same Condition to a WaitSet

Attaching the same Condition multiple times to a WaitSet did not report an error and allowed duplicate attachments. This led to inconsistent behavior: although each attachment appeared successful, calling detach_condition would only remove the condition once, leaving the WaitSet in an inconsistent state.

This issue has been resolved by updating attach_condition to perform a no-op and silently return success if the Condition is already attached. This ensures the internal state remains consistent without requiring additional checks in the application code.

[RTI Issue ID CORE-6857]

5.2.24.14. [Major] Error when parsing an XML with a struct that has an enum member with a default enumerator

If you tried to load the type MyStruct from the following xml:

<enum name="MyKind">
      <enumerator name="Kind0"/>
      <enumerator name="Kind1"/>
      <enumerator name="Kind2"/>
</enum>
<struct name= "MyStruct">
      <member name="an_enum_w_default" type="nonBasic"  nonBasicTypeName= "MyKind" default="MyKind::Kind1"/>
</struct>

The XML parser in the Core Libraries complained because it was not able to find the enumerator name. The above XML is now correctly parsed.

[RTI Issue ID CORE-15919]

5.2.24.15. [Major] XML string literal interpretation divergence between Core Libraries and Code Generator

There was a mismatch in how XML string literals were interpreted between the Core Libraries and Code Generator:

The Core Libraries interpreted string values literally.
Code Generator treated unescaped strings as references, requiring values like “Foo” to be escaped as “Foo” to ensure they were parsed as literal values rather than references.

For example, to achieve the string "Foo", the Core Libraries required default="Foo", and Code Generator required default=""Foo"". This inconsistency led to unexpected or garbled values when using the same XML across different XML parsers.

This divergence has been resolved. Now, both the Core Libraries and Code Generator consistently interpret string constants. You can use default="Foo" in both, and it will correctly resolve to the string literal "Foo".

[RTI Issue ID CORE-14664]

5.2.24.16. [Major] XML parser did not parse scientific notation when exponent included an explicit positive sign

The XML parser didn’t correctly understand the literals expressed in scientific notation when the exponent included an explicit positive sign.

[RTI Issue ID CORE-15933]

5.2.24.17. [Major] Error when parsing an XML with a union that has a member with a default value

If you tried to load the type MyUnion from the following XML:

<union name="MyUnion" extensibility="mutable">
        <discriminator type="int16"/>
        <case>
        <caseDiscriminator value="1"/>
            <member name="member1" default="82" type="int16"/>
        </case>
</union>

It complained with the following error: DDS_XMLTypeCode_getAnnotationParameterValue:Parse error at line 15: default annotation is not supported for optional members. The above XML is now correctly parsed.

[RTI Issue ID CORE-15920]

5.2.24.18. [Minor] Building a Connext application with Wundef warning category could generate unexpected warnings

Building a Connext application with the Wundef category enabled could generate some warnings about undefined preprocessor directives being evaluated. The warning was harmless and had no implications in the final compiled code. The code has been enhanced to prevent the warning.

[RTI Issue ID CORE-15543]