In version 7.2, we improved our handling of ASN.1 comments, as follows.
- When using the "Pretty-print ASN.1" (-asn1) option, comments from type assignments and elements (SEQUENCE/SET/CHOICE components) are now included in the output. Previously, pretty-printed ASN.1 did not include any ASN.1 comments in the output.
- When generating C/C++ code, we previously put ASN.1 comments only for types into the C/C++ comments. We now include ASN.1 comments from elements as well.
- When writing comments, we now try to preserve the position of the comment as it appeared in the ASN.1. We formerly printed all comments before the type assignment with which we associated the comment, even if the comment actually appeared after the type assignment.
When we output ASN.1 comments and ASN.1 syntax, whether the context is pretty-printed ASN.1 or C/C++ comments, we are not simply writing out everything as it appeared in the input. This means we have to associate comments with syntax. Since ASN.1 comments don't have a syntactic relationship to other parts of the ASN.1 syntax, such associations involve a heuristic. In the example below, the comment is potentially associated with either BigNumber or SmallNumber, though common practice suggests it's most likely related to SmallNumber.
BigNumber ::= INTEGER (500..1000) -- This is the type to use for speeds SmallNumber ::= INTEGER (0..30)
Here's a rough description of the heuristic rules we use:
- If the start of a comment comes after some other ASN.1 syntax appearing on the same line, the comment is considered related to that syntax.
- If the start of a comment is preceded, on the same line, only by whitespace, the comment may be related either to syntax that precedes or succeeds the comment.
- If the comment is followed by a type assignment or an element, the first such comment that is not indented, relative to the type assignment or element, is associated with that type assignment or element. Successive comments are also associated with the same item, regardless of indentation.
- Any comments that preceded the first non-indented comment (all of which are indented) are associated with something which precedes those comments. If these comments are immediately preceded by a type assignment or an element, they are associated with that type assignment or element. In any case, they will not be associated with an element or type assignment that follows those comments.
Some examples:
-- comment for Person
Person ::= SEQUENCE {
-- comment for age
age INTEGER, -- another comment for age
-- yet another comment for age
-- comment for name
name UTF8String
} -- another comment for Person
-- yet another comment for Person
-- comment for Winnings
Winnings::= INTEGER (500..1000)
It is possible that these heuristics will associate a comment differently than a human reader would have. Consider this example:
BigNumber ::= INTEGER (500..1000) -- SmallNumber is used for speeds SmallNumber ::= INTEGER (0..30)
Because of the indentation, the comment will be associated with BigNumber, but it obviously actually relates to SmallNumber. Since we try to preserve location when printing, we'll print the comment after the definition of BigNumber, which can give the reader a hint that the comment might actually relate to something else (if the content of the comment were different, this might not be so obvious to the reader).