Path: utzoo!attcan!uunet!cme-durer!libes
From: libes@cme-durer.ARPA (Don Libes)
Newsgroups: comp.lang.c
Subject: Re: Portability across architectures..
Summary: Try ASN.1
Message-ID: <641@muffin.cme-durer.ARPA>
Date: 17 Sep 88 17:46:43 GMT
References: <7038@bloom-beacon.MIT.EDU> <3221@geac.UUCP>
Reply-To: libes@cme-durer.arpa (Don Libes)
Distribution: all
Organization: National Bureau of Standards, Gaithersburg, MD
Lines: 33

There's another possibility besides ASCII and native form: ASN.1

ASN.1 is a set of ISO standards which address the OSI Presentation
Layer - very similar to the problem you face.

The time/space overhead for ASN.1 data encoding is low.  Each datum
has a few extra bytes on it for length and type info but is otherwise
compactly stored.  For example, an ascii string is stored as an ascii
string.  Ints are stored in binary and allow for arbitrary size.

The nice thing is, you can select the way you want the datatype to be
encoded.  E.g., you can have an int encoded as an integer or string or
any of the other appropriate built-in types - and the result is still
portable.  In other words, you have pretty good control over
everything.

You can also define your own datatypes.  For example, I can (and do)
send linked lists between two processes this way.  And they can be
written in different languages, running on different machines and
different operating systems.

ASN.1 is really several pieces.  I believe there is a complete
implementation in ISODE (available via ftp from udel.edu).

We actively use ASN.1 here.  (We tried ASCII, native forms and mixes
of them, but eventually gave up with them.)  We have our own
implementation that one of our hackers wrote.  It's minimal but small
(object code is only 3K) and fast.  It doesn't do any parsing (8824),
just value encoding/decoding (8825), although we write our standards
following the ASN.1 syntax anyway.  (And yes, you can have it, but it
is undocumented.)

Don Libes          cme-durer.arpa      ...!uunet!cme-durer!libes