Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!convex!convex.convex.com!sheley
From: sheley@convex.com (John "Dumptruck" Sheley)
Newsgroups: comp.sys.amiga
Subject: Re: C standard across machines (question).
Message-ID: <sheley.657414748@convex.convex.com>
Date: 31 Oct 90 23:12:28 GMT
References: <43072@eerie.acsu.Buffalo.EDU>
Sender: news@convex.com
Lines: 54

In <43072@eerie.acsu.Buffalo.EDU> v069qqqc@ubvmsd.cc.buffalo.edu (Michael Carrato) 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!)

  There is no C standard which declares that integer types will be stored in
memory `big endian' or `little endian' - that is left completely up to the
architecture you're running on.  C treats the basic types (char, int, short,
long, float, double) atomically, and cares not a bit how the machine stores
data as log as it retrieves the data the same way it stored the data.  This
causes nightmares (and rightly so) to people who do indiscrimant `union'ing
and try to port their code to different cpus.

>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?

  This isn't really wrong - you're just screwed if you try to use the same
data file on an I*M and an Amiga.  There's really nothing you're missing.
The suggestions others have offered are about all you can do if you want
portability.  I could be mistaken, but I believe dbase stores it's numbers
as ASCII.  Not a great example, but there you are.  Something else to
consider, though is how you are going to run indexes to your database tables.
If you allow mixed composite keys (1 or more ASCII fields combined with 1 or
more numeric fields) to be used to build indexes, then it might be better
to store your numbers as ASCII.  The collating sequence of a group of keys
composed of ASCII data and pure binary numbers together will not be what
you want unless the numbers are unsigned.

  By the way, I'm thinking of doing something along those same lines, and
I'm having trouble deciding what mechanism to use for indexing.  Do you plan
to use ISAM, B-tree/balanced B-tree, or hashing?  I'm thinking about ISAM for
sorting speed, combined with extra pointers B-tree kind of searches.  I'd
appreciate any thoughts.

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

John Sheley
Convex Computer Corp.
sheley@convex.com