Decoding routines generated by snacc expect extra EOC octets in a tagged CHOICE

[rbalint]

Hi,

A Debian user reported the issue to Debian BTS ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375470 ):

I found this bug when using snacc to generate the decoding routines for
TAP 3.11 (Transfer Account Procedure Data Record Format, Specification
Version Number 3. GSM Association, Official Document TD.57, 26 May 2005)
and testing them with data files from an external source that are surely
of this particular format. The routines returned an unexpected error:

BDecEoc: ERROR - non zero byte in EOC or end of data reached

The same files could be handled without errors by dumpasn1.

It wasn't easy to find out from where these errors come. I inserted
printf() calls adjacent to the BDecEoc() calls in the generated decoding
routines, and this way I finally found that:

The decoding routines expect (and check the presence of) two consecutive
EOC octets where only one EOC octet is present in my test files (no,
I cannot provide you with them). After deleting the extra code the
files went through decoding without errors.

I haven't had the same kind of problem with earlier versions of TAP 3,
so I searched for an explanation from the changes made in TAP 3
specifications from TAP 3.10 to TAP 3.11, and found that the extra
EOC was expected in the decoding routine at a tagged CHOICE, which
was non-tagged in earlier TAP 3 specifications.

The following is a simplified excerpt of the TAP 3.11 specification:

TAP-0311 DEFINITIONS IMPLICIT TAGS ::=

BEGIN

BasicService ::= [APPLICATION 36] SEQUENCE
{
serviceCode BasicServiceCode OPTIONAL,
transparencyIndicator INTEGER OPTIONAL
}

BasicServiceCode ::= [APPLICATION 426] CHOICE
{
teleServiceCode TeleServiceCode,
bearerServiceCode BearerServiceCode
}

BearerServiceCode ::= [APPLICATION 40] HexString --(SIZE(2))

TeleServiceCode ::= [APPLICATION 218] HexString --(SIZE(2))

HexString ::= OCTET STRING

END

Compile this by snacc. You can find the following sequence of code
in the generated function BDecBasicServiceContent():

BDecBasicServiceCodeContent (b, tagId2, elmtLen2, (v->serviceCode),
&totalElmtsLen1, env);
if (elmtLen1 == INDEFINITE_LEN)
    BDecEoc(b, &totalElmtsLen1, env);
if (elmtLen1 == INDEFINITE_LEN)
    BDecEoc (b, &totalElmtsLen1, env);

One of the if sentences with its BDecEoc() call is too much, it
shouldn't be there!

I haven't checked if the coding functions produce output that is
compatible with the decoding functions (with extra EOC) or if they
are OK.

[apconole]

I have this solved, I believe, with my version of snacc (https://github.com/orgcandman/esnacc-ng); it will be merged to https://github.com/azsnacc/esnacc-ng after some internal testing.