Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!MCC.COM!tomlic
From: tomlic@MCC.COM (Chris Tomlinson)
Newsgroups: comp.protocols.iso.dev-environ
Subject: incorrect handling of CHOICE by posy/pepy
Message-ID: <9103191641.AA29412@yoda.aca.mcc.com>
Date: 19 Mar 91 16:41:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 66

I believe that there is an error in 6.8 (and in 6.0) regarding the
handling CHOICE.

The following example illustrates the error:

FOO DEFINITIONS ::=

BEGIN

A  ::= CHOICE { a T1, b T2 }

T1 ::= [APPLICATION 0] IMPLICIT NULL

T2 ::= [APPLICATION 104] CHOICE
       { a 	[0] IMPLICIT NULL,
	 c 	[1] IMPLICIT NULL }

END

This leads to two problems: 1) the FOO-types.h multiply declares both
"type_FOO_A_a" and "a":

struct type_FOO_A {
    int     offset;
#define	type_FOO_A_a	1
#define	type_FOO_A_a	2
#define	type_FOO_A_c	3

    union {
        struct type_FOO_T1 *a;

        char    a;

        char    c;
    }       un;
};

and 2) the encoder does not generate and the decoder does not expect
the [APPLICATION 104] tag.

My understanding of the ASN.1 standard is that 1) the [APPLICATION 104]
tag should in fact be encoded for transmission and that 2) the above
ASN.1 should produce identical results to the following:

BAR DEFINITIONS ::=

BEGIN

A  ::= CHOICE { a T1, b T2 }

T1 ::= [APPLICATION 0] IMPLICIT NULL

T2 ::= [APPLICATION 104] T3

T3 ::= CHOICE
       { a 	[0] IMPLICIT NULL,
	 c 	[1] IMPLICIT NULL }

END

This version indeeds leads to encoding the [APPLICATION 104] in the
case of a "b" choice for T1 and the BAR-types.h does not suffer from
multiple definitions.

Thanks,
Chris Tomlinson