[comp.protocols.iso.dev-environ] incorrect handling of CHOICE by posy/pepy

tomlic@MCC.COM (Chris Tomlinson) (03/20/91)

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

ghatak@CS.UTK.EDU (03/20/91)

 I await the answer to Mr. Tomlinson's query with interest, for I have
had some dealings with the CHOICE construct too. The results were somewhat
funky, though they were not outright errors ( not that I analysed it in
detail ) as Mr. Tomlinson's example seems to be.

Regards to all,
S. Ghatak