From: sgr@alden.UUCP (Stan Ryckman)
Newsgroups: comp.lang.c,comp.sys.sun.misc
Subject: Re: How to use the same file of structs on PC and Sun?
Date: 27 Aug 92 18:20:50 GMT
Followup-To: comp.lang.c
Organization: Alden Electronics, Westboro, MA

In article <71527@apple.Apple.COM> may@Apple.COM (Patrick May) writes:
>Hi,
>
>     I'm porting an application from an MS-DOS environment to the Sun
>(SunOS 4.1.1).  The app makes heavy use of files opened in binary mode
>to store various structs.  When I tried to use these same files on the
>Sun I found that the Sun compiler came up with a different size for
>these structs than did the MS-DOS compiler (uSoft).  I'd half expected
>something like this, and had intended to do a one-time conversion of
>the affected files.
>
>     Unfortunately, these files may be accessed by the both the Sun
>and MS-DOS versions of the application over, for example, PC/NFS.
>Is there a way to tell the Sun compiler not to do any alignment (if
>in fact that's what's happening) or, alternatively, to tell the
>Microsoft compiler to act the same as the Sun compiler?
>
>Thanks,
>
>Patrick May
>may@apple.com     (posting from, but not working or speaking for, Apple)
>------------------------------------------------------------------------
>                              "A contract programmer is always intense."

As several have pointed out, binary is a bad idea when using something
on more than one machine.  However, assuming you're stuck with
too big of a mess of existing stuff and can't go beat on
the original designer(s) with a wet noodle...:

I didn't see anyone point out that the _first_ thing you need to 
make sure is that nothing is "int" in your structures.  That
may fix many structs that appear to have alignment/padding diffs.
uSoft C makes "int's" 16 bytes; all Sun compilers I've seen use 32 for
int.  You should be able to use long or short (signed or unsigned)
interchangeably (with the same _size_) on these machines (but not
necessarily others).  However, as has been pointed out by others,
you have the "big-vs.-little-endian" problem, and you'll have
to decide whether the Sun or MS-DOS version of the application
is going to be the one stuck with flipping the bytes around
(both on input and output).

I don't know whether floating point (if you use it) is binary
compatible or not, but if it is you'll have to flip those bytes
too.

You can probably avoid alignment differences by putting the
largest types first, then down to char variables last.  If you
have nested structures (say) where the two compilers refuse
to align them the same, you can throw in explicit padding
("junk" variables) to make the compilers agree.  (This is not
ANSI or anything; I just am 99% sure it will work with these
two particular machine/compiler combinations.)  uSoft C "likes"
to align many things on 16-byte boundaries because of the
braindead PC architecture.  Of course then, you _also_ have
to do the one-time conversion of the existing files.

On the other hand, you may still find it less work to go with
ASCII text as others have suggested.

I wish you luck.

Stan.
--
One little, two little, three little Endians
Four little, five little, six little Endians...
    Stan Ryckman   sgr@alden.UUCP
Newsgroups: comp.lang.c