Duplicate definition on INTEGER value definition

[pierrotbui]

Hello Community,

I am evaluating ASN1SCC for ETSI ITS-G5 messages. After removing extensibility markers, I still got compiler errors on duplicate INTEGER values definitions. Example duplicate.asn:
AccelerationValue ::= INTEGER {
outOfRange (101),
unavailable (102)
} (0..102)

AngleConfidence ::= INTEGER {
outOfRange (126),
unavailable (127)
} (1..127)

asn1scc -c -uPER duplicate.asn
duplicate.asn:5:6: error: Duplicate definition: outOfRange

How to handle this compile error ? additional option to pass to asn1scc ?
I built the release 36 of asn1scc on Windows.
regards,
Pierre

[maxime-esa]

I think it's a bug. @usr3-1415 can you check?
The constants are prefixed by the type name so there seems to be no reason for the compilation error

const AccelerationValue AccelerationValue_outOfRange = 101;
const AccelerationValue AccelerationValue_unavailable = 102;

[usr3-1415]

Currently, named integer values within an INTEGER type are being treated as global scope integer value assignments. Your example illustrates this behavior succinctly:

AccelerationValue ::= INTEGER {
	outOfRange (101),
	unavailable (102)
} (0..102)

is currently interpreted by ASN1SCC as:

AccelerationValue ::= INTEGER  (0..102)
outOfRange AccelerationValue ::= 101
unavailable AccelerationValue ::= 102

This internal transformation by ASN1SCC is indeed the cause of the error message regarding the duplicate definition of 'unavailable'.

I totally get that this behavior isn't what was expected with named integer values and I see how it can be a hiccup. The issue is on my radar and I’m looking to sort it out in an upcoming release of ASN1SCC. However, I want to be upfront about the complexity of this fix. It requires a tweak in the internal AST (Abstract Syntax Tree) of the compiler, which is a bit of a big deal since it will have an impact on all backends. So, it’s not just a quick patch.

Just to lay all cards on the table, right now, it's not at the top of my fix-it list as I am hustling on some other key enhancements. That being said, if Maxime decides to bump this up the priority ladder, I’ll definitely shift gears and tackle it sooner.

[maxime-esa]

Is there a workaround ? Replacing INTEGER with ENUMERATED would work identically I think in C, no?

[usr3-1415]

Replacing INTEGER with ENUMERATED might seem like a feasible workaround at first glance. However, there's a subtle but important distinction between the two types that would affect the functionality. The current definition of AccelerationValue allows for any value between 0 to 102, inclusive. If we switch to an ENUMERATED type, it would restrict the values strictly to outOfRange and unavailable, excluding any other value. This would change the underlying data representation in C and isn't equivalent to the original definition. So, unfortunately, it wouldn't work as a direct substitute in this case.

[pierrotbui]

Hello,

Thanks for your time examining this problem. I got clear explanations and the issue is identified and will be handled in future.
I'll make workaround by changing the named values of these integers in their asn1 modules.

Regards,
Pierre

[maxime-esa]

Yes, until this is handled in the compiler the easiest is probably to declare them manually after the type as constants like this:

AccelerationValue-outOfRange AccelerationValue ::= 101
AccelerationValue-unavailable AccelerationValue ::= 102