[LCP]struct size

[Mike & Penny Novack]

Robert,
    If  THAT is your problem (data created by one implementation to be
read by another)

> Because the data was in a serial stream of a bunch (several thousand)
> mostly char items.  The data is normally sent between a DOS app
(Borland
> C) and an embedded 8051 (Keil C) or one of several PICs (Hitech PIC-C)
> (and there are some 68HC908's (Cosmic C) thrown in the system for good
> measure).  All of those compilers produced packed structs (char
> alignment _is_ the natural alignment on an 8 bit processor).
>

    There are two (reasonable) solutions neither of which involves doing
something like trying to "pack".

a) Add to each application a data handler to output (or input) in
portable form (written in the matching implementation) -- The only
portable format recognized as valid to C is ASCII. If you want
applications to "cooperate" they should be written to do this BUT IT'S
SLOW/BULKY. Notice that even if you are writing standard C you cannot
count on a "binary" file written by by one program to be read by another
(or even back by the same program*) unless they are all recompiled --
and obviously you cannot "recompile" the program that produced and
existing file (can't go back in time). BINARY FILES ARE NOT PORTABLE**.

b) Write (in the current C version) file conversion programs to act as
"bridges". But these should not depend upon implict matching of formats
(like by the "pack" you suggest) but explicit bit manipulation. In other
words, make very visable precisely what you are doing. The reason for
this is that again, you want your "conversion bridges" to spell out what
they are doing so that they do not mysteriously fail when recompiled
under a different version of the compiler.

    In any case, you might not be able to "match" just with things like
packing. For example, suppose the writing application was from an
implementation using 16 bit for short and int and 32 bit for long while
your current implementation uses 32 bit for all three (that's legal -- C
standards do NOT guarantee that "short" is actually shorter than "int").

Mike Novack

* -- ie: You shouldn't assume that a binary file written by a program
last year can be read back in by that program if it has been recompiled
in the interval EVEN IF THERE WERE NO SOURCE CODE CHANGES.

** -- Because ASCII files ARE bulkier and require in and out time (eg:
converting binary numbers to ASCII and then back) it may be justified
writing a "production system" passing binary files. In which case do not
consider development "complete" without including writing the "bridges"
binary file to ASCII and ASCII to binary file. Even though these will
presumably not be used in normal production, they will have been tested
and available for that day in the future when all of a sudden they might
become very useful. (eg: we recompile system B and it can no longer
handle the feeds from system A -- well we can simply insert the two
"bridges" -- this at least gets us through the night and provides time
to design/write/test a permamnet fix. AND -- in any case, those files
intended to be stored long term (say for legal purposes) should
certainly be converted to their ASCII equivalent.