Fast DDS-Gen silently accepts invalid IDL with duplicate enum literals and drops the duplicate

[wuyuqa]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

Fast DDS-Gen should reject this IDL and return a non-zero exit status, because duplicate enum literals are invalid IDL declarations.

CycloneDDS rejects the same input:

Declaration 'ZERO' collides with an earlier declaration of 'ZERO'

OpenDDS rejects the same input:

illegal redefinition ::test::ZERO, ::test::DuplicateEnumState, ::test::ZERO

Current behavior

Fast DDS-Gen exits with status 0 and generates type support files:

Processing the file duplicate_enum_literal.idl...
Generating Type definition files...
Generating Type Support files...
Generating TypeObjectSupport files...
Adding project: duplicate_enum_literal.idl

The generated C++ enum silently contains only three enumerators:

enum class DuplicateEnumState : int32_t
{
    ZERO,
    ONE,
    MAX
};

The generated TypeObject support also builds only three enumerated literals, with ordinals 0, 1, and 2. The second ZERO from the input IDL is dropped without any diagnostic.

Steps to reproduce

Minimal reproducer

duplicate_enum_literal.idl:

module test {
  enum DuplicateEnumState { ZERO, ONE, MAX, ZERO };

  struct DuplicateEnumSample {
    long id;
    DuplicateEnumState state;
  };
};

Steps to reproduce

Run Fast DDS-Gen:

fastddsgen -d /tmp/fastddsgen_duplicate_enum_out -replace duplicate_enum_literal.idl
echo "$?"
grep -R -n "enum class DuplicateEnumState\\|ZERO\\|ONE\\|MAX" /tmp/fastddsgen_duplicate_enum_out

### Fast DDS version/commit

## Affected versions tested

- Fast DDS-Gen: 4.3.0
- Fast DDS: 3.6.2.0
- CycloneDDS idlc: 11.0.1
- OpenDDS: 3.34.0
- Java runtime used by Fast DDS-Gen: OpenJDK / Temurin 21.0.11

### Platform/Architecture

Ubuntu Focal 20.04 amd64

### Transport layer

Intra-process

### Additional context

_No response_

### XML configuration file

```xml

Relevant log output

Network traffic capture

No response

[wuyuqa]

Why this matters

Although the generated code is made compilable by dropping the duplicate literal, accepting and silently normalizing invalid IDL is still harmful:

• The schema submitted by the user is not the schema represented by the generated code or TypeObject.
• Invalid IDL can pass a Fast DDS-Gen based validation/codegen pipeline but fail in CycloneDDS, OpenDDS, or other IDL toolchains.
• In mixed DDS environments, this creates a schema compatibility and deployment failure mode: one implementation accepts the type contract while others correctly reject it.
• Tooling that stores, audits, signs, or distributes IDL may record the original invalid schema, while Fast DDS registers/generated code for a normalized schema.
• Users receive no diagnostic that a declaration was ignored, making the resulting type contract surprising and difficult to debug.

This is a schema integrity and interoperability issue rather than a CDR runtime memory-safety issue.

Specification reference

OMG IDL 4.2 defines enumerations as ordered lists of enumerators. It also defines the general name-scoping rule that an identifier can only be defined once in a scope. The spec further states that enumeration value names are introduced into the enclosing scope and are treated like any other declaration in that scope.

Therefore, declaring ZERO twice in the same enum declaration should be rejected.

Reference: https://www.omg.org/spec/IDL/4.2/PDF

Probable root cause

In Fast DDS-Gen's bundled idl-parser, enum literals are added through EnumTypeCode.addMember(), which delegates to MemberedTypeCode.addMember().

MemberedTypeCode.addMember() detects duplicate member names by checking a LinkedHashMap and returns false when a member name already exists:

if (!m_members.containsKey(member.getName()))
{
    m_members.put(member.getName(), member);
    return true;
}

return false;

However, the enum grammar action ignores this return value:

EnumMember new_field = new EnumMember(name);
...
enumTP.addMember(new_field);

By comparison, struct member parsing checks the return value of addMember() and throws a ParseException when a member was previously defined.

The enum path should similarly report a parse/semantic error when enumTP.addMember(new_field) returns false.