Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!ucsd!pacbell.com!tandem!netcom!mcmahan
From: mcmahan@netcom.UUCP (Dave Mc Mahan)
Newsgroups: comp.sys.amiga
Subject: Re: C standard across machines (question).
Message-ID: <15828@netcom.UUCP>
Date: 30 Oct 90 07:32:10 GMT
References: <43072@eerie.acsu.Buffalo.EDU>
Organization: Dave McMahan @ NetCom Services
Lines: 52


 In a previous article, v069qqqc@ubvmsd.cc.buffalo.edu writes:
>
>I am writing a general purpose database in C. I'm developing it for 
>the company I work for so I'm doing it with the ibm XT's they have in mind.
>However, I would like to eventually Amiga-tize it and release it as
>(probably) shareware. I would therefore prefer to make the program (as 
>well as the database format) as portable as possible.
>
>The problem is, (correct me if I'm wrong) Intel machines are "little
>endian" whereas Motorolas are "big endian". I assume C adopts one of
>these standards to maintain protability of files between machines.
>My question is, which is the C standard, and how do I ensure that a database
>created on the ibm version will not be garbage on the Amiga version. 
>(To add to the confusion, I'm doing the development on a sun... I have
>no idea what the sparc standard is!)

You are correct in your observation.  Alas, there is no standard for the order
of bytes written to a file (that I have ever heard of or seen).  There really
aren't any gaurantees that you will even be using the same number of bytes for
an integer on one machine that you use on another.  Some compilers like to
use 16 bit integers, some prefer 32 bit integers.  About all K&R will let you
count on is that a long integer is at least as big as a 'normal' integer.
There isn't really even a definate standard as to the number of bits per
character, although most machines that are capable use 8 bits per character.
Some older mainframes use 6 bits and some use 9.   'C' is able to accept code
that uses the ASCII character sequence as well as EBCDIC (although functions
like strcmp() have special versions for EBCDIC machines).  About the only
thing you can REALLY count on is that you can read a byte and write a byte.
If you want to be really portable, you have to pack and un-pack bytes as they
are read or written to disk.  There really isn't any absolute gaurantee that
writing a binary 16 bit value on a 68000 CPU will write the most significant
byte first.

>As it stands now, I'm using fread() and fwrite() for my file i/o.
>I KNOW this must be wrong, since it's simply a binary image transfer.
>Is there any general way to read/write a block of data so that this 
>mess can be resolved, or do I have to write code to output the data 
>byte-by-byte?

To absolutely gaurantee portability, you have to read and write on a byte by
byte basis.  It's a pain, but it's the only way I know of.  Of course, you
can always make some assumptions.......

The other solution is to keep all your info as ASCII characters.  It tends
to make your data files much bigger and slow down access times, but last time
I checked, everyone still reads english from left to right, right?    :-)

>Mike Carrato
>SUNY at Buffalo, senior in computer engineering.

    -dave