5.4. What’s Fixed in 4.1.0
[Critical]: System-stopping issue, such as a crash or data loss.
[Major]: Significant issue with no easy workaround.
[Minor]: Issue that usually has a workaround.
[Trivial]: Small issue, such as a typo in a log.
5.4.1. Fixes Related to C, Traditional C++, and Modern C++ Generated Code
5.4.1.1. [Major] Aliases and Arrays Not Correctly Initialized in Unions
In previous Code Generator releases, aliases and arrays were not
correctly initialized in the union’s constructors. This issue is now
resolved; Code Generator now initializes aliases and arrays using
aggregate initialization in the member’s declaration, instead of using
rti::core::fill_array
in the constructor.
[RTI Issue ID CODEGENII-842]
5.4.1.2. [Major] Compile-Time Error when Using -constructor with Types Containing Sequence of Pointers
After 6.0.1, if you created an IDL with a sequence of pointers, and generated code for C++98 with the -constructor flag, you encountered a compile-time error, because Code Generator was assigning NULL to the sequence. This problem has been fixed. The code now generates the constructor correctly when using a sequence of pointers.
[RTI Issue ID CODEGENII-1596]
5.4.1.3. [Major] Typo in a Condition in ndds_standalone_type.h
In the file <NDDSHOME>/resource/app/app_support/rtiddsgen/standalone/include/ndds_standalone_type.h, a preprocessor condition incorrectly checked if the variables RTI_LINUX or RTI_DARWIN were defined. This condition is now fixed.
[RTI Issue ID CODEGENII-1657]
5.4.1.4. [Major] Generated Code for C++11 Didn’t Compile When Using @external int8/uint8/octet
When generating code for C++11, if a type had a member that was an external int8, uint8, or octet, the code was generated correctly, but the compilation failed due to an invalid cast. This problem has been fixed. Now the generated code will compile and work as expected.
[RTI Issue ID CODEGENII-1727]
5.4.1.5. [Major] Forward Declaration Did Not Work for C and C++98 When Using Incomplete Type in a Sequence
If you generated code for C or C++98 for an IDL that contained a forward declaration, and you used the forward-declared type in a sequence before defining it, the code failed at compilation time:
struct MyStructFD;
struct MyStruct{
sequence <MyStructFD> member_1;
};
struct MyStructFD {
long member_FD;
};
This problem is now fixed. If you generate code for the example above, it will generate correctly and compile. For more information about forward declarations, see IDL Forward Declaration in the Core Libraries User’s Manual.
[RTI Issue ID CODEGENII-1807]
5.4.1.6. [Minor] C++11 Examples Fail When Using External Annotation
Examples generated for C++11 for a type with external members would fail if used directly. This was because a sample with an external could not be sent with a null value. This issue has been fixed by initializing the first-level external members.
Note that higher-level external members will still cause examples to fail, such as a type with a member of another type that has an external. In this case, the external must be initialized by the user.
[RTI Issue ID CODEGENII-1747]
5.4.1.7. [Minor] DDS Topic Type Name Value May Return a Different Value Than the One Used in the typeCode
If you used a keyword as the name of a type or a module, dds::topic::topic_type_name<T>::value() would return a different value than the one used in the typeCode. This issue has been fixed. Now, dds::topic::topic_type_name<T>::value() and the type code are populated with same type name.
[RTI Issue ID CODEGENII-1817]
5.4.2. Fixes Related to C# Generated Code
5.4.2.1. [Major] Copy Directive (@copy) Was Not Available for C#
The following directives are now functional when generating code with Code Generator for C# :
//@copy "//copy this message for all the languages"
//@copy-declaration "//copy this message for all the languages, just where the types are being declared"
//@copy-cs "//copy this message just for C#"
//@copy-cs-declaration "//copy this message just for C#, just where the types are being declared"
[RTI Issue ID CODEGENII-1502]
5.4.2.2. [Major] Incorrect C# Generated Code When a Union Based on the Alias of an enum is in a Different Module from the enum
If you generated code for C# for an IDL with a union that was based on an enum defined in a different module, the code would not compile. This issue has been resolved.
[RTI Issue ID CODEGENII-1797]
5.4.2.3. [Major] Negative enums Produced Compilation Error in C#
The generated code for an enumerator type may have caused a compilation error in C#. This happened when one of the values was negative and the enumerator was a member of an aggregated type:
enum MyStatus { ProblemEnum = -1, Correct = 0};
The C# compiler complained that the assignation of the negative value must be between parentheses.
This issue is fixed. Now, the generated code is correct and will compile.
[RTI Issue ID CODEGENII-1799]
5.4.2.4. [Minor] Compilation Error When Using copy-c Directive Inside of a Structure in C#
Previously, if Code Generater generated code for C# from an IDL in which there was a type with a //@copy directive inside, the code would be generated, but not compile. Now, the generated code compiles, and the //@copy directives are available in C#.
[RTI Issue ID CODEGENII-1713]
5.4.2.5. [Minor] C# Generated Code Does Not Compile When a Sequence or Array is Named hash
In the generated code for an IDL, a type with a member called hash would conflict with the local variable hash in the method GetHashCode(). This has been fixed by adding this. to hash when referring to the name of a member inside the method GetHashCode().
[RTI Issue ID CODEGENII-1714]
5.4.3. Fixes Related to Java Generated Code
5.4.3.1. [Critical] Possible Data Loss Deserializing a Union with an enum Based Discriminator When dds.sample_assignability.accept_unknown_enum_value is 1
When the property dds.sample_assignability.accept_unknown_enum_value was set to 1 and the type was an appendable union, data could be lost or corrupted during deserialization.
For the following example:
enum ColorV1 {
RED_1
};
// Subscriber
@interpreted(true)
union ColorUnionV1 switch (ColorV1) {
case RED_1:
long m1;
};
@interpreted(true)
enum ColorV2 {
RED_2,
GREEN_2
};
// Publisher
@interpreted(true)
union ColorUnionV2 switch (ColorV2) {
case RED_2:
long m1;
case GREEN_2:
octet m3;
};
If a subscriber that expected a ColorUnionV1 received a ColorUnionV2 sample with ColorV2.GREEN_2 as discriminator, an exception would be thrown because the subscriber would try to read ColorUnionV1.m1, which is bigger than the data in the wire, ColorUnionV2.m3.
The issue has been fixed. Now, if a subscriber that expects a ColorUnionV1 receives a ColorUnionV2 with the discriminator set to ColorV2.GREEN_2, the received ColorUnionV1 sample will be:
Set to the default value if dds.sample_assignability.accept_unknown_union_discriminator is 1, or;
Dropped if dds.sample_assignability.accept_unknown_union_discriminator is 0.
[RTI Issue ID CODEGENII-1823]
5.4.3.2. [Major] Incorrect Values for Serialized Sample Max and Min Size in Java Generated Code
When Code Generator generated Java code for an IDL with mutable types or types with optional members, you could get an incorrect value for the following methods:
enum MyStatus { ProblemEnum = -1, Correct = 0};
get_serialized_sample_max_size
enum MyStatus { ProblemEnum = -1, Correct = 0};
get_serialized_sample_max_size
get_serialized_sample_min_size
This issue has been resolved.
[RTI Issue ID CODEGENII-655]
5.4.3.3. [Minor] Issue With Java Generated Code When Using Unbounded Support Flag
When generating code for Java using the flag for unbounded support (-unboundedSupport), there was an issue with the generated USER_QOS_PROFILES.xml. The property dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size was contained in a pair of <value> tags, and the properties dds.data_writer.history.memory_manager.java_stream.min_size and dds.data_writer.history.memory_manager.java_stream.trim_to_size were in another pair. This is now fixed; all the properties are contained in the same group of <value> tags.
[RTI Issue ID CODEGENII-1631]
5.4.4. Fixes Related to Python Generated Code
5.4.4.1. [Major] Type idl.int8 Generation for Python Inconsistent With Other APIs
The type generated for octet, uint8, and int8 for Python was idl.int8, but this caused inconsistency with other APIs in which this type is not supported. Now Code Generator generates the type idl.uint8 for octet, uint8, and int8.
[RTI Issue ID CODEGENII-1753]
5.4.4.2. [Major] Incorrect Generated Python Code if a Union Based on an enum Didn’t Have the Default Enumerator, in a Branch of the enum
If an IDL had a union based on an enum, and this union didn’t have a branch with the default enum value, the Python-generated code was not correct. Now, the generated code is correct, even if you have a union without the default enum value.
[RTI Issue ID CODEGENII-1771]
5.4.4.3. [Major] @allowed_data_representation Annotation Not Processed Correctly in Python
The annotation @allowed_data_representation ignored the parameter passed in the IDL/XML and always produced the same generated code in the Python decorator.
idl.allowed_data_representation(xcdr2=False, xcdr1=True)
This release fixes the problem. Now, the generated code in the decorator will match the parameter passed to the annotation @allowed_data_representation in the IDL/XML.
[RTI Issue ID CODEGENII-1773]
5.4.4.4. [Trivial] Python Generated README.txt when It Should not Have
Code Generator always generated the README.txt file for Python even when it should not have. It should have generated the README.txt file only when the -example <arch> or -create <makefiles> command-line argument was used. Now, README.txt won’t be generated for Python unless the -example <arch> or -create <makefiles> command-line argument is used.
[RTI Issue ID CODEGENII-1775]
5.4.5. Fixes Related to Generated Code (Multiple Languages)
5.4.5.1. [Major] Invalid Generated Code when a Type was Inside a Set of Modules With Repeated Names
Code Generator would generate code for C++98, C++11 and C# that did not compile when the following occurred:
There was a type inside a set of modules, and;
Two of those modules had the same name.
For example:
module A{
module B{
module A{
struct myStruct {
long m1;
};
};
};
};
This issue has been corrected for all affected languages.
[RTI Issue ID CODEGENII-609]
5.4.5.2. [Major] Code Generator did not Allow Forward Declaration of Interfaces
Code Generator did not allow forward declaration of interfaces. Now it does. A forward declaration of interfaces can be added to the IDL, and the code will be generated.
[RTI Issue ID CODEGENII-1720]
5.4.5.3. [Minor] Code Generator Allowed Setting Scoped Names or Negative Values as a Size
Code Generator allowed setting scoped names and negative values as a size, for an array, string, or sequence, resulting in a compilation time error. Now, if something other than a positive integer is used as a size, Code Generator fails.
[RTI Issue ID CODEGENII-407]
5.4.5.4. [Minor] Code Generation Fails for Arrays and Sequences of Aliases with Default, Max, or Min Values
Code Generator does not support generating code for arrays and sequences with default, max, or min values. However, Code Generator would generate code for an IDL that set a default, max, or min value in an alias (i.e. typedef) and then used that alias as the base type for a sequence or array. For example:
@min(0)
@max(20)
@default(10)
typedef long myLongTypedef;
struct Foo {
myLongTypedef myLongArray[2];
sequence<myLongTypedef> myLongSequence;
};
In this release, Code Generator will fail to generate code for the above IDL the same way it would fail for a sequence with default, max, or min values.
[RTI Issue ID CODEGENII-1314]
5.4.5.5. [Minor] -Wsign-conversion and -Wconversion Warnings Removed from Generated Code
Code Generator introduced -Wsign-conversion and -Wconversion warnings in the generated code. All of these warnings have now been removed from the generated code.
[RTI Issue ID CODEGENII-1633]
5.4.5.6. [Minor] Code Generator did not Check if Base Interface Exists when Inheriting
Code Generator did not check if the base interface of inheritance existed; as a result, it generated code with issues. Now, if an interface inherits from an interface that doesn’t exist, code generation will fail.
[RTI Issue ID CODEGENII-1744]
5.4.5.7. [Minor] Code Generator Allowed Inheriting from Forward-Declared Structure
The specification doesn’t allow inheritance from a forward-declared structure. Code Generator allowed this behavior and generated code with issues silently. Now if a structure inherits from a forward-declared structure, code generation will fail.
[RTI Issue ID CODEGENII-1745]
5.4.5.8. [Minor] Code Generator Slowed Down When There Were Multiple Levels of Aliases
An IDL/XML file with multiple levels of aliases could cause Code Generator to slow down significantly, due to recursive value calculations. The issue has been fixed. Now, Code Generator calculates the values once and stores them to use them when necessary.
[RTI Issue ID CODEGENII-1810]
5.4.5.9. [Minor] Prevent Code Generation for typedefs with Inconsistent Default, Max, or Min Values
Previously, you could generate code for the following IDL:
@max(5)
typedef long myLongTypedef;
@min(10)
typedef myLongTypedef myLongTypedef2;
struct Foo{
myLongTypedef2 m1;
};
However, when these typedefs are resolved, they result in a member with a minimum value of 10 and a maximum value of 5, which is not valid. This issue has been resolved. In this release, if you try to generate code that shows inconsistencies between max, min, or default values when the typedefs are resolved, Code Generator will fail.
[RTI Issue ID CODEGENII-1815]