asn1 parameterized types with extension

[vances]

Describe the bug
Compilation of an ASN.1 module fails if it contains a parameterized type with an extension marker.

To Reproduce

T {}

DEFINITIONS ::= BEGIN

        Type {Type} ::= SEQUENCE {
                i Type, 
                ...
        }

        Instance ::= Type{INTEGER}

END

$ erlc T.asn1 
Internal error: error:function_clause
[{asn1ct_gen,do_gen_record_1,
             [[{'EXTENSIONMARK',14,undefined}]],
             [{file,"asn1ct_gen.erl"},{line,1277}]},
 {asn1ct_gen,do_gen_record_1,1,[{file,"asn1ct_gen.erl"},{line,1290}]},
 {asn1ct_gen,do_gen_record,3,[{file,"asn1ct_gen.erl"},{line,1271}]},
 {asn1ct_gen,gen_record,5,[{file,"asn1ct_gen.erl"},{line,1234}]},
 {asn1ct_gen,pgen_hrltypes,4,[{file,"asn1ct_gen.erl"},{line,1166}]},
 {asn1ct_gen,pgen_hrl,2,[{file,"asn1ct_gen.erl"},{line,1126}]},
 {asn1ct_gen,pgen,3,[{file,"asn1ct_gen.erl"},{line,69}]},
 {asn1ct,generate,4,[{file,"asn1ct.erl"},{line,855}]}]

Expected behavior
I am expecting the parameterized types to be ignored and encode/decode functions for other (simple) types to be generated.

Affected versions
Reproduced with Erlang/OTP 23 (asn1-5.0.8).

Additional context
The ASN.1 modules I am working with which highlighted this issue are in 3GPP TS 29.078 CAMEL Application Part (CAP).

[vances]

I had been unclear about how extension markers were encoded but after empirical testing I can see that they are not encoded in BER. So the simple solution for my purposes becomes removing the ellipsis making this less of a bug and more a feature request.

T1 {}

DEFINITIONS ::= BEGIN

        With ::= SEQUENCE {
                i INTEGER,
                ...
        }

        Without ::= SEQUENCE {
                i INTEGER
        }

END

1> asn1ct:compile('T', [ber]).
ok
2> rr("T.hrl"). 
['With','Without']
3> {ok, With} = 'T':encode('With', #'With'{i = 42}), 
3> {ok, Without} = 'T':encode('Without', #'Without'{i = 42}),
3> With == Without.
true

[KennethL]

I have looked at this and I think it is a bug which we should fix. You are correct in that the extensionmarkers are not encoded, but they have significance when decoding data. If you decode a SEQUENCE which contains additional fields (after the extensionmarker) you decoder will accept it if there was an extensionmarker but will reject it if there is no extensionmarker (in your ASN.1 module which the decoder is generated from).

The original crash is when generating records and I think it is a bug to try to generate a record for a parameterized type at all.
I think the parameterized types should only be considered for generation of code when they are instantiated. But I have to check this further.

[KennethL]

Fixed in OTP 23.3.2