Incompatibility between V3 and V4: <typename>_REQUIRED_BYTES_FOR_ACN_ENCODING

[AlexanderFabisch]

This macro is generated by a previous version for each type in a generated C header. I could not find it for all types in V4.

See here for an example.

[usr3-1415]

Can you provide the ASN.1 grammar that generates the specific examples? Also, please identify the ASN.1 types for which the _REQUIRED_BYTES_FOR_ACN_ENCODING is not generated.

[maxime-esa]

I think the the macros are not generated because in V4, the inner types are encoded inline. There are no _Encode functions generated for the inner anonymous types in a SEQUENCE. There are macros generated only for standalone types, as they are the only ones that have an Encode function.

[maxime-esa]

you can see it here. I don't think there is a type named LaserScan-remission in the ASN.1 grammar, and this is why there is no macro generated for this type. The field most likely has a inner type of this form : SEQUENCE (SIZE (2000)) OF T-Int32))

In V3 there were _Encode function (and corresponding macros generated for them) for all the intermediate types generated to support anonymous inner types. That's not the case anymore in V4 so the macros are not generated. George can you confirm?

[AlexanderFabisch]

Can you provide the ASN.1 grammar that generates the specific examples? Also, please identify the ASN.1 types for which the _REQUIRED_BYTES_FOR_ACN_ENCODING is not generated.

The ASN.1 type is defined here.

[AlexanderFabisch]

you can see it here. I don't think there is a type named LaserScan-remission in the ASN.1 grammar, and this is why there is no macro generated for this type. The field most likely has a inner type of this form : SEQUENCE (SIZE (2000)) OF T-Int32))

In V3 there were _Encode function (and corresponding macros generated for them) for all the intermediate types generated to support anonymous inner types. That's not the case anymore in V4 so the macros are not generated.

OK, that seems to be the case. So this is a breaking change.

@maltewi are you (or ESROCOS) aware of that? @planthaber FYI

[maxime-esa]

In what context are you using the macros generated for internal types (that don't appear in the ASN.1 model) ?

The reason for this change is actually coming from a major new feature in ACN, that lets you refine locally the encoding of fields of a SEQUENCE.

Say you have these types:

T1 ::= INTEGER (0.255)
T2 ::= SEQUENCE {
   a T1
}

In that case, you will get macros for T1 and T2 because both are "PDU". - types for which you may call the Encode function.

In ACN, with V4 you could have different encodings for the field a of T2 and for type T1:

T1 [size 64, encoding pos-int]
T2  [] {
   a [size 32, encoding pos-int] 
}

The encoding of the field a of T2 will therefore not call the T1_Encode function, as it can have different constraints.

If you have an anonymous inner type:

T3 ::= SEQUENCE {
  a INTEGER (0..255)
}

Then the encoding of a will always be inline, and depending on the ACN property you will provide (the field a could have a different constraint if T3 was also used as the type of a field of another SEQUENCE, and so on).

If an T3_a_Encode function (and corresponding macro) was generated, it would not be called by the encoder of T3. This is why it is not generated.

In V3, there was a single T3_a_Encode function that was called when T3 was encoded. It was not possible to have different encodings of a depending on the context (this pattern happens in the encoding of the PUS-C telecommands, where for example the APID type is sometimes encoded with 11 bits, sometimes with 16 bits).

I hope this clarifies the issue. The idea was to provide more control/power with ACN and simplify the code at the same time, by not generating functions which are not used/needed.

If you have a use case that requires these functions/macros please let us know so that we better understand your need.

[AlexanderFabisch]

Thanks for the explanation.

In what context are you using the macros generated for internal types (that don't appear in the ASN.1 model) ?

I'm struggling to find it at the moment. Maybe the problem just vanished mysteriously. :) It was something related to the converters from generated C types to other C++ types in this repository. But maybe there were just some old generated C headers created by V3 mixed with new C implementation files created by V4. A result of our overly complicated build system. Unfortunately, I don't know and cannot reproduce the problem at the moment. I think we can close this issue. I will write if it occurs again.

[maxime-esa]

OK! Thanks for the feedback. Closing