From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: True Portability?
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 2 Sep 1992 22:13:23 GMT

krc@wam.umd.edu (Kevin R. Coombes) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>jlnance@eos.ncsu.edu (JAMES LEWIS NANCE) writes:
>>>
>>>If you write binary files and expect to share these between machines,
>>>or if you use network connections between machines, then you have to
>>>wory about wheather a machine is big or little endian, but if you
>>>explicitly take this into account, you can still be portable.
>>
>>No, you won't.
>>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?
>
>Kevin Coombes <krc@math.umd.edu>

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.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: bame@hpfcbig.SDE.HP.COM (Paul Bame)
Date: Mon, 24 Aug 1992 19:59:00 GMT
Subject: Re: Threads quotation (Re: A question on style ...)
Organization: HP SESD, Fort Collins, CO