Can one access asn1ct's ASN.1 parser?

Oliver Korpilla oliver.korpilla@REDACTED
Mon Jan 4 14:00:59 CET 2021

Hello, Kenneth.

Yes, this would address the problem I'm trying to solve.

Currently we have problems with keys that represent names that have
changed or been removed from a particular ASN.1 spec, or in some cases,
recognizing keys that have been put into the wrong map altogether. (So,
incompatible spec changes and user errors.)

All of these three errors could be spotted by checking if a map only
contains keys valid to an ASN.1 SEQUENCE during the encoding stage.

 From our point of view, the performance hit might be acceptable since
we're maintaining a testing solution which ultimately values correctness
over performance. (Also, if this was a compiler option, we might
relegate such checking to unit tests for our message builders without
affecting the encoders used elsewhere.)

Are there are any plans to provide this functionality or is it merely a
token for discussion?

Thank you,

On 04.01.2021 13:47, Kenneth Lundin wrote:
> We have discussed to add functionality in the generated encoder (for
> the maps variant) which checks that the map does not contain any
> "unknown" keys, that is only allow keys which are corresponding to the
> names in the ASN.1 spec. Probably this should be activated with a new
> compiler option since it will probably have some negative impact on
> performance.
> Is this what you need as well or are you thinking of some other
> solution (or other problem)?
> There is no API for the parse tree but there is an internal
> intermediate format used by the backends.
> /Kenneth, Erlang/OTP Ericsson
> On Mon, Jan 4, 2021 at 11:44 AM Oliver Korpilla
> <oliver.korpilla@REDACTED <mailto:oliver.korpilla@REDACTED>> wrote:
>     Hello,
>     is it possible to reuse the parsing part of asn1ct? Does it generate
>     some intermediate structure?
>     We have been using the "maps" instead of the "records" version of the
>     generated codecs for a while. However, we found recently that we
>     missed
>     several instances of incompatible name changes because there's no name
>     checking for the map members. Unknown map members just get omitted.
>     I would like to investigate if I could add a layer for my
>     project's use
>     preventing that, but I have no desire to write another ASN.1
>     parser for
>     that.
>     Is there an API for accessing this information?
>     Thank you,
>     Oliver
>     --
>     Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> <>

Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.

More information about the erlang-questions mailing list