--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: Decoding routines generated by snacc expect extra EOC octets in a tagged CHOICE
- From: Kari Pasanen <kari.pasanen@starnet.fi>
- Date: Mon, 26 Jun 2006 11:14:44 +0300
- Message-id: <20060626081444.13218.36190.reportbug@localhost.localdomain>
Package: snacc
Version: 1.3bbn-9
Severity: important
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages snacc depends on:
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libsnacc0c2 1.3bbn-9 ASN.1 to C or C++ or IDL compiler,
Versions of packages snacc recommends:
ii libsnacc-dev 1.3bbn-9 ASN.1 to C or C++ or IDL compiler,
pn snacc-doc <none> (no description available)
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.
--- End Message ---