5.28. Other

5.28.1. [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.28.2. [Critical] Data races on architectures with weak memory model

Several data races on systems with a weak memory architecture, such as ARM and PowerPC, have been fixed in this release. Some of these data races could have led to undefined behavior or crashes in different parts of Connext.

[RTI Issue ID CORE-14893]

5.28.3. [Major] Error sending batch when batch size exceeded transport MTU and included unregister or dispose messages

A DataWriter configured to use batching may have failed to send a batch to the destination addresses associated with a transport (e.g, UDPv4) if the batch size exceeded the message_size_max (MTU) of the transport and the sample that caused the batch to become larger than the message_size_max was either an unregister or a dispose message.

Now, the batch is automatically flushed when exceeding the minimum message_size_max across all installed transports, regardless of what type of message is added to the batch to cause it to exceed the message_size_max.

[RTI Issue ID CORE-15233]

5.28.4. [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.28.5. [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.28.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.28.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.28.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.28.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.28.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.28.11. [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.28.12. [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.28.13. [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.28.14. [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.28.15. [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.28.16. [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". Code Generator treats both default="Foo" and default=""Foo"" as the same—both result in the literal string Foo to avoid breaking running applications.

[RTI Issue ID CORE-14664]

5.28.17. [Major] Printing an IDL union with an enum discriminator could have produced an incorrect output

When printing an IDL union with an enum discriminator, the resulting case labels may have been incomplete if the enum types were defined in a separate module.

[RTI Issue ID CORE-14654]

5.28.18. [Major] Incorrect CPU assignment when using THREAD_SETTINGS_CPU_RR_ROTATION in receiver_pool

There was an incorrect CPU assignment for the receive threads when using the THREAD_SETTINGS_CPU_RR_ROTATION setting in the receiver_pool. Specifically, all the receive threads were assigned to the first CPU listed in the cpu_list.

[RTI Issue ID CORE-13211]

5.28.19. [Major] Missing implementation of RTI_DL_DistLogger_get_version(), RTI_DL_DistLogger_get_api_build_version(), and RTI_DL_DistLogger_get_api_version_string()

The implementation of the APIs RTI_DL_DistLogger_get_version(), RTI_DL_DistLogger_get_api_build_version(), and RTI_DL_DistLogger_get_api_version_string() was not compiled, so using them resulted in a “function declared but not defined” failure at compile time. The APIs can now be used as expected.

[RTI Issue ID DISTLOG-243]

5.28.20. [Minor] Python API was not included in patch releases *

Starting with release 7.3.0.7, the Python API wheels are now included in the host bundle for patches.

[RTI Issue ID INSTALL-1110]

5.28.21. [Minor] IDL annotations printed after typdef specifier

When using to_string on IDL types where annotations (such as @default) and a typedef were specified, those annotations were printed after the typedef specifier. This behavior has been changed to print the typdef specifier after the necessary annotations.

[RTI Issue ID CORE-14857]

5.28.22. [Trivial] Possible data race when creating DomainParticipants

During the creation of a DomainParticipant, it was possible to run into a data race due to the use of the localtime or gmtime API by other threads in Connext. There was no functional impact of this data race; however, it has been fixed by using the safe versions of those APIs available on the different operating systems.

[RTI Issue ID CORE-14877]

5.28.23. [Trivial] Printing a type with an annotation using an enum produced an incorrect output

When printing a type with an annotation using an enum, the resulting annotations contained the ordinal instead of the enum type name.

[RTI Issue ID CORE-14729]

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