0000411: Improve rename policy for enumerants

The "rename policy" was discussed over mail a couple of years ago. Here is the thread: RE: [taste-dev] r6613 - trunk/DMT/asn1scc.3 George Mamais to: 'Maxime Perrotin' 10/06/2013 12:04 Cc: ttsiodras Hide Details From: "George Mamais" <gmamais@semantix.gr> To: "'Maxime Perrotin'" <Maxime.Perrotin@esa.int> Cc: <ttsiodras@semantix.gr> History: This message has been replied to. Yes you are right. I will add also the no rename policy From: Maxime Perrotin [mailto:Maxime.Perrotin@esa.int] Sent: Monday, June 10, 2013 12:53 PM To: George Mamais Cc: ttsiodras@semantix.gr Subject: Re: [taste-dev] r6613 - trunk/DMT/asn1scc.3 I would suggest a third policy, for Ada, without any prefix, since they are not required by the language (policy A or B are only needed because of SPARK, if I understood correctly, but they add unnecessary noise to the code). No? On Mon, 10 Jun 2013 11:45:36 +0200, George Mamais <gmamais@semantix.gr> wrote: Hi Maxime, This is to let you know, that in the next release of the ASN.1 compiler, I plan to change this behavior. In particular the user will be able to set rename policy: Policy A (existing one, i.e. Mychoice_a_PRESENT, b_PRESENT, etc) Policy B (existing one, i.e. Mychoice_a_PRESENT, Mychoice_b_PRESENT, etc) The default policy for C will be Policy A (in order to avoid breaking existing code), while the default policy for Ada (where the existing user code is much less) will be Policy B. Please tell me if you are OK with this. Kind regards, George From: George Mamais [mailto:gmamais@semantix.gr] Sent: Thursday, June 06, 2013 5:55 PM To: 'Maxime Perrotin' Cc: 'ttsiodras@semantix.gr' Subject: RE: [taste-dev] r6613 - trunk/DMT/asn1scc.3 You are right it would be better to have the behavior you describe. However, that behavior was adopted in the previous version ASN.1 compiler and the new compiler copied that behavior (otherwise user code would break). Kind regards, George From: Maxime Perrotin [mailto:Maxime.Perrotin@esa.int] Sent: Thursday, June 06, 2013 4:22 PM To: George Mamais Cc: ttsiodras@semantix.gr Subject: Re: [taste-dev] r6613 - trunk/DMT/asn1scc.3 But then it would be better to have a consistent naming. All enumerant should be built with the same rules to make the code using a particular type portable. In the example below, having Mychoice_a_PRESENT next to b_PRESENT is confusing, and makes it impossible to reuse the same type and code if the type is copied in a different ASN.1 grammar (since the naming is computed based on the neighbouring types). On Thu, 06 Jun 2013 15:20:03 +0200, George Mamais <gmamais@semantix.gr> wrote: Hi Maxime, Indeed, in Ada is not need. However, Spark has problem with this (it is an error), so I decided to handled it like in C. Piotr grammar has enums with the same enumerant names, so this how I discovered this issue. Kind regards, George From: Maxime Perrotin [mailto:Maxime.Perrotin@esa.int] Sent: Thursday, June 06, 2013 3:47 PM To: George Mamais Cc: ttsiodras@semantix.gr Subject: Fwd: [taste-dev] r6613 - trunk/DMT/asn1scc.3 Hi George, From the log of the new version of the compiler, I noticed this (from Thanassis): * emum names are not required to be unique I do not understand - this creates a regression in some code because the naming of the choice determinant (in Ada) is now prefixed with the type name in some cases, like in C : TYPE asn1SccMyChoice_selection IS (MyChoice_a_PRESENT, b_PRESENT); Is there a reason for that ? In Ada, this should not be needed, contrary to C (and until now it was working well without it). Thanks Maxime

This will not be an easy fix because I am not really sure what I have to do. I read the book of Mr. Dubuisson about named INTEGERs. Here the relevant text: "ASN.1, therefore, provides a specific syntax for the INTEGER type: the list of integers, where every one of them is preceded by its identifier (which begins with a lower-case letter); this list is denoted in curly brackets after the keyword INTEGER. The error code of a floppy can then be modeled with the type: ErrorCode ::= INTEGER { disk-full(1), no-disk(-1), disk-not-formatted(2) } stupid-error ErrorCode ::= disk-full these identifiers have only a local scope, i.e. they can only be used to define values of type ErrorCode like stupid-error for example. The same number can obviously not be named by two different identifiers and a given identifier cannot name two different numbers. The named integers are not necessarily ordered or consecutive and the list of integers in curly brackets is not restrictive " The key word is that these identifiers have only a *local scope*. Unfortunately, the current implementation of ASN1SCC does not handle named INTEGERs as local scope values but as global value assignments. I.e. it transforms them into value assignments as follows: hello INTEGER ::= 1 hello INTEGER ::= 2 (which of course, in this case, does not make any sense and the compiler emits the error) In our ASN.1 compiler, it is even possible to do the following B ::= INTEGER { hello (20) } (0..100) C ::= SEQUENCE (SIZE (0..hello)) OF INTEGER So, the problem is not the lack of renaming (as we do in enums) but the fact that named INTEGERs are handled like global value assignments. Now, if we implement the ASN.1 standard as described in Mr. Dubuisson's book then the only actual use of named Integers is to define other value assignments such as stupid-error ErrorCode ::= disk-full (this is an example of Mr Dubuisson, not mine) which is very limited. In this case, named INTEGERs values will not appear in the generated code as constants (only the stupid-error will appear) and hence there is no need for any renaming. Which means that if the protocol designer of the PUS had in mind another usage for hello, then this will not appear in the generated code. What I am trying to say is that perhaps this is not a high priority issue and can be easily handled if we change the grammar. Please tell me your thoughts on this issue.

A think a local scope means that if you have two different types you cannot assign a value of the first type to a variable of the other type. so indeed if you declare: A ::= INTEGER { hello(1) } (0..255) B ::= INTEGER (0..255) In the code it should be forbidden to have a variable of type B and assign value `hello` to it. Of course I know that C does not respect this basics of data typing... With Ada, this is enforced, if you have something like type A is new integer range 0..255; type B is new integer range 0..255; A_hello : constant A := 1; var : B := A_hello; -- Compilation error With that in mind, it does make sense to have a systematic renaming (TypeName_ConstantName, as in A_hello) Without renaming, the original case: A ::= INTEGER { hello (1) } (0..100) B ::= INTEGER { hello (2) } (0..100) which is valid ASN.1, had to chance to exist in C, since it is forbidden to declare two constants of the same name with different values. A trick in Ada would make it possible using polymorphism: type A is new integer range 0..100; type B is new integer range 0..100; function hello return A is (1); function hello return B is (2); c : B := hello; -- will assign 2 d : A := hello; -- will assign 1 This is nice (including syntactic sugar - no parenthesis), and the compiler would probably optimize things out to have no overhead (function call) at runtime but since this is not possible in C, let's not go there :-( Back to our problem: If you translate into: hello INTEGER ::= 1 hello INTEGER ::= 2 instead of hello A ::= 1 hello B ::= 2 then indeed there is no chance that it works as local scope values Does a translation to A-hello A ::= 1 B-hello B ::= 2 imply complex changes on your side? I think that would make it comply to the ASN.1 semantics that you explained from the book of Mr. Dubuisson Perhaps I am missing something. If you think it's the case, a short term solution is to reject grammars that have these kind of conflicting named integers constants with an error message (rather than at compile time).