From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: Re: True Portability?
Organization: University of Maryland, College Park
Date: Thu, 3 Sep 1992 18:31:52 GMT

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>krc@wam.umd.edu (Kevin R. Coombes) writes:
>>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>>Basically binary files are not portable.
>>>(Code to read/write binary files can be portable, but the files themselves
>>>are not.)
>>
>>I'm not sure I understand this statement. Yesterday I transferred some
>>DVI files (produced by TeX) and some MAT files (produced by Matlab)
>>from my Sun at work to my PC at home. I was still able to print the
>>DVI files, and to load the MAT files and continue my computations.
>>
>>Both those files are binary data files used by the programs I mentioned.
>>Clearly, they are portable, since implementations of the software for
>>different platforms can both use them. Yes, the software has to be ported
>>as well; that's not in question. Could you elaborate on what you mean
>>when you say that binary files are not portable?
>
>Sorry, I should have been a bit more careful in my wording.
>(I did say "basically..." ;-)
>It is not enough simply to take big/little endianness into account.
>You also need to take into account differing integer sizes,
>different padding of structures, different representations of
>floating point numbers, etc., etc.
>
>Roughly speaking, the only things that you can portably write to a binary
>file and then read back again are variables of type "char" with values from
>0-127 or variables of type "unsigned char" with values of type 0-255.
>
>Anyway, the fact that you have ported files from one platform to another
>successfully does not mean that those files will be portable to the
>next platform you come accross. I don't know about MAT, but I strongly
>suspect that TeX is not *completely* portable. 
>In fact TeX itself was written in Pascal (or rather Web), so
>it is basically irrelevant as far as C goes, but I did manage to find
>some code from "dvi2ps" on my system. This comes from "dvi2ps.c"; it is
>part of the SignExtend function, which is used to convert the raw bytes of
>the DVI file into a signed integer:
>
>    /* NOTE: This code assumes that the right-shift is an arithmetic, rather
>    than logical, shift which will propagate the sign bit right.   According
>    to Kernighan and Ritchie, this is compiler dependent! */
>
>    x<<=32-8*n1;
>    x>>=32-8*n1;  /* sign extend */
>
>Not only does it assume that right-shift is arithmetic, it also assumes
>that int is 32 bits (x is declared as an int earlier in the code).
>As it happens, I think that these assumptions are all correct for both
>your PC and your Sun, so this would work fine on both of those machines.
>It might not work on something like a DEC Alpha.
>I think that TeX itself also makes assumptions about the size of integers
>and bytes... there are a lot of magic numbers like 256 and 65536 in the
>source code.
>
>Binary files *can* be portable, but is does require a lot of work, and it
>is easy to introduce assumptions which may not hold on all possible systems.
>Sometimes it's easier (when text files are not efficient enough) to simply
>use non-portable binary files, and provide a program to convert them to and from
>portable text format so that they can be transported from one platform to
>another.

TeX itself has been ported to lots of different machines; citing the
obvious weaknesses in an implementation of dvi2ps (at least one version
of which I helped write -- possibly the one cited) does not say anything
about the portability of the binary file. If you're interested, the place
to look is in the documentation of the program DVItype. This is available
from the standard ftp places where TeX can be found. (Get dvitype.web,
run it thorught TeX, and then run it through a dvi processor to view it.)
This contains a description of the DVI file format. The only assumption
that it makes is that a DVI file is a stream of 8-bit bytes. Some of those
bytes will have to be put back together later to represent large numbers
(never exceeding 32-bits, however). The way you get at those bytes and the
way you reassemble them will differ from one machine to another, but
a DVi file should be usable on any machine that can read a stream of 
8-bit bytes.

Matlab is harder (and the documentation unavailable, since it's a
commercial product) mainly because it must store floating point data.
Each MAT file stores as its first (?) byte a code which identifies the
machine on which the file was produced. I assume they handle portability
in some grungy fashion that needs to know that information.

Kevin Coombes <krc@math.umd.edu>
Newsgroups: comp.lang.c