Malformed PID_TYPE_INFORMATION in Endpoint Discovery messages

Hello, I am attempting to make DustDDS and CycloneDDS-Python interoperate.

I run on 2 different archs (amd64 and arm64) the same following simple use case: 2 topics with a data type each, one for each direction. The DustDDS side has one DataReader and one DataWrite, as well as the CycloneDDS-Python side.

On amd64, data exchanges seem ok but the DustDDS side doesn't acknowledges CycloneDDS-Python Data(r). This only causes problems in reliable mode.
On arm64, I get the same behavior as in amd64, plus the Data(w) from CycloneDDS-Python is never recognized by DustDDS.

The thing is that, inspecting RTPS messages with Wireshark, I noticed that in its Data(r) and Data(w) messages, CycloneDDS-python includes a PID_TYPE_INFORMATION which doesn't seem ok : the Dependent Type Count is negative

Type Information
    Minimal
        Type Id With Dependencies
            Type Id With Size
            Dependent Type Count: -1850208753
            Dependent Type IDs [13694875]

And Wireshark tags the messages as "Malformed":

[Malformed Packet: RTPS]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

This appears so on both archs, for Data(r) and Data(w).

For added context, the data types are generated by the CycloneDDS idlc into python files. They are simple small structs, all with the @annotate.final.

Start by reproducing the two-topic exchange with CycloneDDS-Python and DustDDS on amd64 and arm64, then inspect the generated Python files and RTPS captures in Wireshark. Done means PID_TYPE_INFORMATION is no longer reported as malformed and reliable Data(r) and Data(w) interoperate on both architectures.