From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,78b2880bc7e78e39 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-30 09:36:08 PST Path: supernews.google.com!sn-xit-03!supernews.com!news-out.usenetserver.com!news-out-sjo.usenetserver.com!news.tele.dk!62.112.0.25!newsfeed.online.be!ams.uu.net!news.mailgate.org!smtp.well.com!not-for-mail From: xanthian@well.com (Kent Paul Dolan) Newsgroups: comp.lang.ada Subject: Re: RISC Date: Fri, 30 Mar 2001 17:31:58 +0000 (UTC) Organization: Mailgate.ORG Server - http://www.Mailgate.ORG Message-ID: <200103301731.JAA11673@well.com> NNTP-Posting-Host: smtp.well.com X-Trace: news.mailgate.org 985973518 11571 208.178.101.27 (Fri, 30 Mar 2001 09:31:56 -0800 (PST)) X-Complaints-To: smtp.well.com@abuse.net abuse@mailgate.org NNTP-Posting-Date: Fri, 30 Mar 2001 17:31:58 +0000 (UTC) Mail-From: xanthian@well.com from smtp.well.com [208.178.101.27] X-URL: http://www.Mailgate.ORG Xref: supernews.google.com comp.lang.ada:6259 Date: 2001-03-30T17:31:58+00:00 List-Id: References=<9kws6.218$94.1074@www.newsranger.com> Ted Dennison said: => ASN.1 had a lot of this type of stuff. Take the standard => "length octet" for instance (...please!). Bit 8 selects => between "short form" and "long form". In "short form" the => other 7 bits indicate the length of the contents. In "long => form", the other 7 bits indicate how many of the following => bytes are used to determinte the length of the rest of the => contents. (Remember, no problem can't be solved by another => level of indirection...) However, if bit 8 is on and the => rest of the bits are off, then it indicates that we are => using "indefinite form", where two terminator octets at the => end of the contents determine the length. => A week of wrestling with this kind of stuff several years => ago was enough to convince me that there are always going => to be some formats that just cannot be nicely handled at a => high-level with something like a rep clause. Don't put ASN.1 too far in the past. As of Q1 1998, at least, it was alive and well as the data format for SNMP, version 1, and as well as it worked, I can't imagine it being easily replaced. The other way of looking at this issue is probably that if ASN.1 (and BER, _its_ underlying standard) were directly supported as data type families in a compiled language, the questions of worrying how to deal with stream oriented data, or of fighting with representations, would go away. In ASN.1 and BER, those are solved problems, so long as you put each at both ends of the transaction. The folks who designed ASN.1 took on a very hard problem: how do you standardize the representation of dynamically bounded amounts of indefinite precision data, and frankly, strange as the mechanisms seem at first encounter, they are quite elegant once the cultural shock has worn away. Elegant and easy to implement are not synonyms. The horror of knowing that you are going to be doing _everything_ at the bit level has been adequately expressed in another posting in this thread. I ran into identical issues in 1983, tasked with providing a library (in C for the IBM big box of the day, I misremember which) to let other programmers translate UDAF (Uniform Data Access Format, I think) Honeywell 36 bit data to formats suitable for storage on IBM 32/64 bit format media. The answer that worked to translate 20,000 2400' data tapes was to do it all one bit at a time, with certain cheesy optimizations where possible. Cheers! xanthian. -- Kent Paul Dolan -- Posted from smtp.well.com [208.178.101.27] via Mailgate.ORG Server - http://www.Mailgate.ORG