home *** CD-ROM | disk | FTP | other *** search
- Path: 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
-
- 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
-