Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mcnc!rti!xyzzy!kan
From: kan@dg-rtp.dg.com (Victor Kan)
Newsgroups: comp.software-eng
Subject: Re: How Do Interface Description Languages Work? (a little long)
Summary: XDR has it, text is ok, but unreliable, hoggish
Keywords: XDR text printf
Message-ID: <1648@xyzzy.UUCP>
Date: 6 Oct 89 22:04:02 GMT
References: <12697@joshua.athertn.Atherton.COM> <8092@goofy.megatest.UUCP>
Sender: usenet@xyzzy.UUCP
Reply-To: kan@mutley.dg.com ()
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 124

In article <8092@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>
>From article <12697@joshua.athertn.Atherton.COM>, by joshua@athertn.Atherton.COM (Flame Bait):
>
>
>> If you want a better IDL, I'd look at Sun's XDR system. 
>
>
>Then, not finding it there, look elsewhere.
>
>
>> [It] was designed from the begining to be a general purpose data language
>> (ie. to be used for more than just remote procedure calls).  This difference
>> in design philosophy shows.  Also, XDR can support any data type used by
>> C ...
>
>Huh?
>
>It can't even handle directed acyclic graphs, even with all the pointers
>nicely pointing to the "tops" of the structures. It turns them into
>trees. On a cyclic graph, it will get into a loop and spew data until
>something bursts.

I've never done this, but I assume you have tried and know it behaves
this way.

>
>There are other problems with XDR. It uses binary format for integers,
>floating point, etc.. The formats are exactly the ones used internally in
>Sun workstations. (Amazing coincidence that.) So if you use only
>Sun workstation, there is no data-conversion necessary. 

This is true, but there's nothing inherently wrong with this scheme.
It would be stupid to use a scheme that no existing computer uses, wouldn't
it (unless some really smart person comes up with the perfect, never before
seen format)?  So it might as well be their own.

>If you don't, get
>ready to start programming. You may have to write conversion routines for
>going between IEEE floating-point (XDR standard) and whatever else you have:
>IBM or MIT or some other floating-point format. I don't think those routines
>are provided.

This statement makes it hard to believe that you've even read the xdr man page.
Of course those routines are provided.  xdr_float(), xdr_int(), xdr_double(),
etc. are provided to do what's necessary.

Here's a quote from the man page (this may be a copyright infringement, but
I don't think they'd mind in this case):

          xdr_float(xdrs, fp)
          XDR *xdrs;
          float *fp;

               A filter primitive that translates between C floats and
               their external representations.  This routine returns one
               if it succeeds, zero otherwise.

This means that any implementation of the XDR protocol on ANY machine,
IBM, MIT or otherwise, will include routines to translate the native C
format to the XDR format for ints, floats, etc..  It's just like the 
TCP/IP routines/macros (e.g. htons()) that convert words and long words 
to network byte ordering.  On some lucky machines, those routines/macros
are null; on others they require a little bit shuffling.

True, XDR does not provide services to convert from every format to every
other format.  But that would be silly; by using a single, universal
format that every XDR supporting architecture understands, you end up
with easier implementation and greater portability.  While not every
architecture currently supports XDR, implementation of XDR would be fairly
simple (at least for systems programmers who would do the job).

Each vendor only has to write code to convert from their proprietary 
format to XDR.  They don't have to provide translation for the N 
other formats in use.  Portability naturally follows from this 
(barring proprietary handling of the XDR format, which is certainly 
not the case).

I can think of few cases where a complete translation system is the 
best solution.  There are some of course (especially in the PC arena), 
but they are generally in the application level
(Lotus 123 vs. Supercalc vs. Framework format, etc.), not the 
low level of XDR.

For a real life example, look at human language.  There are dozens
of dialects of Chinese spoken in mainland China.  But because they all 
use a single, universal language format (the written form), everyone
can understand what everyone else is saying (i.e. writing).

>
>So, why not just do what XDR should have done... use text to represent
>integers and reals? Everybody has printf and scanf. Good idea, but there
>is no provision for automatic conversion of text from ascii (the unspoken
>XDR standard) to ebcdic and back to ascii.
>
>Perhaps the worst thing about XDR is that if you use it, you may be
>tempted to use RPC.
>

Text is a good idea, but it's much more expensive than a universal 
binary format (time and space wise).  Everybody does have printf and scanf.
But those routines are generally poorly written considering how often 
they are used and abused.

I took an OS course where programming assignments were device drivers.
Due to the limited access to the target experimental hardware,
printf() in C was the first assignment (perhaps as a weed out for the
programming part of the course -- it worked!).  But since it was an 
advanced OS course, we had to pretend we didn't have any library 
routines to work with - no ecvt(), malloc(), varargs, etc.  We were only
allowed to use putc() since a tty driver with our own putc() was the 
next assignment.

Printf is HARD to write correctly; in fact, most (if not all) companies
don't write it correctly.  The PhD student/instructor showed us how no 
commercial printf() he had seen could live up the the man page specs. 
Bugs cropped up most often on conversions for floating point numbers and
field width specifiers.  This included System V, Sun, HP, Vax, Masscomp 
and Microsoft C.  Hopefully, things have gotten better since then, 
but I doubt it.

| Victor Kan               | I speak only for myself.               |  ***
| Data General Corporation | Edito cum Emacs, ergo sum.             | ****
| 62 T.W. Alexander Drive  | Columbia Lions Win, 9 October 1988 for | **** %%%%
| RTP, NC  27709           | a record of 1-44.  Way to go, Lions!   |  *** %%%