[LCP]struct size <offline>

[Bill Rausch]

Yes I understood what you were saying but couldn't resist commenting anyway.

Any file format is portable so long as you know the definition of 
that format. For example, once upon a time I wrote some programs to 
read old tapes containing, among other things, VAX binary floating 
point in all its various permutations on another non-VAX computer. 
Yuck. But it can be done.

Anyway, I was thinking more in terms of picking a "neutral" binary 
format and having everything written in that format. There is a 
certain amount of conversion necessary when reading on non-native 
machines but it's manageable if the format is known.

The issue of compiler changes changing the layout does matter 
somewhat, but even there you can always read the pieces and build the 
original structure again in memory. It's still faster to do that than 
to read and translate an ASCII file.

Bill

At 3:58 PM -0400 8/21/01, Mike & Penny Novack wrote:
>  > At 10:25 AM -0400 8/19/01, Mike & Penny Novack wrote:
>>  >existing file (can't go back in time). BINARY FILES ARE NOT
>PORTABLE**.
>>
>>  Depends on what you mean by portable.  You can use things like
>>  hton(), ntoh(), etc. and get very good results.  That is how most
>>  network communications is done.
>>
>
>Offline because a bit more "production" oriented than suitable for this
>list.
>
>The context in which I mean "binary" is related to the original question
>"just how much space does this structure occupy?". In other words, if I
>have an application which writes such structures out to some file (they
>might be read in by another) then I cannot expect this to be portable.

Correct.

>All the components would have to be compiled by the same version of the
>compiler, etc.
>
>That can be a great nuisance when files are sent between shops but as I
>was trying to point out, also a problem over time. You can of course
>"remake" all the components of a system but that only solves the problem
>of CURRENT passing of files. Say I have a system which creates such
>files, perhaps a component of that system produces some printout report
>from the file. You change some component of the system, recompile
>EVERYTHING (because the compiler may be different than at the time of
>the last previous change) and everything still works OK. But what
>happens when the auditors say "please run us a copy of that report from
>the yearend file of six years ago". OOPS, at the time THAT file was
>created the creating program had been compiled by some earlier version
>of the compiler (which may have assigned "slack" differently).
>
>Hey -- one of my fun activities used to be emergency writing of
>"bridges" to convert some old file to match the current layout.
>
>Mike
>
>_______________________________________________
>This is the Linux C Programming List
>:  http://lists.linux.org.au/listinfo/linuxcprogramming List


-- 
  Bill Rausch, Software Development, Unix, Mac, Windows
  Numerical Applications, Inc.  509-943-0861   bill at numerical.com