Article View: comp.protocols.iso
Article #65Re: ASN.1 -> C API (was ASN.1 tools information)
From: Christian Huitema
Date: Tue, 21 Jul 1992 14:39
Date: Tue, 21 Jul 1992 14:39
47 lines
2827 bytes
2827 bytes
A couple of practical remarks following the previous discussion.
1) Regarding CLIDT Guy Genilloud. When I read this, I could not help
thinking "typical ISO kitchen sink technology". I consider that it is more
practical to examine one language -- say C, or C++ -- and to tailor a precise
ASN.1 mapping for that language. By the way, what is ASN.1 itself, if not a
programming-language-independant data description language?
2) Regarding the various size of integers, and the piloting by the "range". I
would like to do something very simple, and as practical as possible:
* use "short" whenever the range is inside -2**7 .. +2**7,
* use a to be defined long integer library whenever the range is
outside -2**31 .. +2**31
* use "long" in all other cases.
Remember that we want portability. Portability accross compilers is one thing,
but portability accross hardware platforms is quite important too!
The alternative is to provide a set of data types that would be redefined for
each and every platform. I bet that all compilers do this, but I also bet that
to let them agree on a common strategy will be .. "interesting".
3) Regarding type rewriting, or simplification, as mentioned by Andrew
Worsley. I understand the potential impact of this technique, which indeed
play a great role in performance and code size optimization -- and
arbitration. But the algorithms that are used here are a somewhat sensitive
part of the compiler, and I would not beg that two compilers perform the same
rewriting. If we specify anything thing different from just mechanically
processing the ASN.1 input, it will have to be very simple and very clear..
4) Regarding "extensible" data types, as mentioned by Bancroft Scott. We seem
to have a problem here. Take the exemple of a type:
X ::= SEQUENCE {
a[0] Foo,
b[1] Bar }
Which get extented in a revised version of a protocol into:
X ::=SEQUENCE {
a[0] Foo,
b[1] Bar,
c[2] NewData OPTIONAL }
I would suppose that the initial version is translated in C as:
typedef struct {
Foo a,
Bar b }
Now, just explain me how I am supposed to pass information on the extra
component "NewData", should it be present?
Christian Huitema
Technical Details
Message-ID:
<24878@sophia.inria.fr>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!corton!sophia!mitsou.inria.fr!huitemaReferences:
<Jul.4.13.21.15.1992.16175@caip.rutgers.edu> <1992Jul7.062240.28306@mel.dit.csiro.au> <Jul.7.21.52.48.1992.25963@caip.rutgers.edu> <1992Jul9.181147.9215@porthos.cc.bellcore.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!corton!sophia!mitsou.inria.fr!huitema From: huitema@mitsou.inria.fr (Christian Huitema) Newsgroups: comp.protocols.iso Subject: Re: ASN.1 -> C API (was ASN.1 tools information) Message-ID: <24878@sophia.inria.fr> Date: 21 Jul 92 14:39:09 GMT References: <Jul.4.13.21.15.1992.16175@caip.rutgers.edu> <1992Jul7.062240.28306@mel.dit.csiro.au> <Jul.7.21.52.48.1992.25963@caip.rutgers.edu> <1992Jul9.181147.9215@porthos.cc.bellcore.com> Sender: news@sophia.inria.fr Organization: INRIA Sophia Antipolis, France Lines: 47