home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / iso / 958 next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.7 KB

  1. Path: sparky!uunet!mcsun!corton!sophia!mitsou.inria.fr!huitema
  2. From: huitema@mitsou.inria.fr (Christian Huitema)
  3. Newsgroups: comp.protocols.iso
  4. Subject: Re: ASN.1 -> C API (was ASN.1 tools information)
  5. Message-ID: <24878@sophia.inria.fr>
  6. Date: 21 Jul 92 14:39:09 GMT
  7. 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>
  8. Sender: news@sophia.inria.fr
  9. Organization: INRIA Sophia Antipolis, France
  10. Lines: 47
  11.  
  12. A couple of practical remarks following the previous discussion.
  13.  
  14. 1) Regarding CLIDT Guy Genilloud. When I read this, I could not help
  15. thinking "typical ISO kitchen sink technology". I consider that it is more
  16. practical to examine one language -- say C, or C++ -- and to tailor a precise
  17. ASN.1 mapping for that language. By the way, what is ASN.1 itself, if not a
  18. programming-language-independant data description language?
  19.  
  20. 2) Regarding the various size of integers, and the piloting by the "range". I
  21. would like to do something very simple, and as practical as possible:
  22.       * use "short" whenever the range is inside -2**7 .. +2**7,
  23.       * use a to be defined long integer library whenever the range is
  24.         outside -2**31 .. +2**31
  25.       * use "long" in all other cases.
  26. Remember that we want portability. Portability accross compilers is one thing,
  27. but portability accross hardware platforms is quite important too! 
  28.  
  29. The alternative is to provide a set of data types that would be redefined for
  30. each and every platform. I bet that all compilers do this, but I also bet that
  31. to let them agree on a common strategy will be .. "interesting".
  32.  
  33. 3) Regarding type rewriting, or simplification, as mentioned by Andrew
  34. Worsley. I understand the potential impact of this technique, which indeed
  35. play a great role in performance and code size optimization -- and
  36. arbitration. But the algorithms that are used here are a somewhat sensitive
  37. part of the compiler, and I would not beg that two compilers perform the same
  38. rewriting. If we specify anything thing different from just mechanically
  39. processing the ASN.1 input, it will have to be very simple and very clear..
  40.  
  41. 4) Regarding "extensible" data types, as mentioned by Bancroft Scott. We seem
  42. to have a problem here. Take the exemple of a type:
  43.    X ::= SEQUENCE {
  44.      a[0] Foo,
  45.      b[1] Bar }
  46. Which get extented in a revised version of a protocol into:
  47.    X ::=SEQUENCE {
  48.      a[0] Foo,
  49.      b[1] Bar,
  50.      c[2] NewData OPTIONAL } 
  51. I would suppose that the initial version is translated in C as:
  52.   typedef struct {
  53.       Foo a,
  54.       Bar b }
  55. Now, just explain me how I am supposed to pass information on the extra
  56. component "NewData", should it be present?
  57.  
  58. Christian Huitema
  59.