Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #57121 > unrolled thread

porting from 32-bit to 64-bit with fine-tooth comb?

Back to article view | Back to comp.lang.c

Contents

  porting from 32-bit to 64-bit with fine-tooth comb? mbjorn@y7mail.com - 2015-02-07 15:33 -0800
    Re: porting from 32-bit to 64-bit with fine-tooth comb? wssimms@gmail.com - 2015-02-07 16:56 -0800
    Re: porting from 32-bit to 64-bit with fine-tooth comb? jt@toerring.de (Jens Thoms Toerring) - 2015-02-08 00:59 +0000
      Re: porting from 32-bit to 64-bit with fine-tooth comb? Keith Thompson <kst-u@mib.org> - 2015-02-07 17:22 -0800
        Re: porting from 32-bit to 64-bit with fine-tooth comb? jt@toerring.de (Jens Thoms Toerring) - 2015-02-08 01:43 +0000
          Re: porting from 32-bit to 64-bit with fine-tooth comb? raltbos@xs4all.nl (Richard Bos) - 2015-02-08 16:16 +0000
    Re: porting from 32-bit to 64-bit with fine-tooth comb? Richard Damon <Richard@Damon-Family.org> - 2015-02-07 20:02 -0500
    Re: porting from 32-bit to 64-bit with fine-tooth comb? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-08 02:18 +0000
    Re: porting from 32-bit to 64-bit with fine-tooth comb? Bartc <bc@freeuk.com> - 2015-02-08 11:08 +0000
    Re: porting from 32-bit to 64-bit with fine-tooth comb? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-02-09 21:20 +0000
    Re: porting from 32-bit to 64-bit with fine-tooth comb? Nobody <nobody@nowhere.invalid> - 2015-02-09 21:35 +0000
    Re: porting from 32-bit to 64-bit with fine-tooth comb? Lőrinczy Zsigmond <nospam@for.me> - 2015-04-03 16:07 +0200
      Re: porting from 32-bit to 64-bit with fine-tooth comb? James Kuyper <jameskuyper@verizon.net> - 2015-04-03 11:21 -0400
      Re: porting from 32-bit to 64-bit with fine-tooth comb? Barry Schwarz <schwarzb@dqel.com> - 2015-04-03 09:36 -0700
        Re: porting from 32-bit to 64-bit with fine-tooth comb? Lőrinczy Zsigmond <nospam@for.me> - 2015-04-03 19:10 +0200
    Re: porting from 32-bit to 64-bit with fine-tooth comb? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-04 21:05 +0000
      Re: porting from 32-bit to 64-bit with fine-tooth comb? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-04 23:13 -0700
        Re: porting from 32-bit to 64-bit with fine-tooth comb? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-11 04:19 +0000
          Re: porting from 32-bit to 64-bit with fine-tooth comb? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-10 23:53 -0700
            Re: porting from 32-bit to 64-bit with fine-tooth comb? Richard Damon <Richard@Damon-Family.org> - 2015-04-11 10:54 -0400
            Re: porting from 32-bit to 64-bit with fine-tooth comb? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-11 15:59 +0000

Page 1 of 2  [1] 2  Next page →

#57121 — porting from 32-bit to 64-bit with fine-tooth comb?

I got this in a mailing list for a FOSS package that I use:

"Another thing to note when running old code on 64-bit platforms is to
inspect the struct definitions that are used directly to store or read
binary data. There's no standard way to guarantee compatibility but
gcc has a "packed" pragma which should do the right thing combined
with explicit padding where needed,"

Is this a problem, that different word lengths can screw up 
structures?  Can unsigned int, for example, change length going from
a 32-bit system to 64?

[toc] | [next] | [standalone]

#57122

Am Sonntag, 8. Februar 2015 08:33:53 UTC+9 schrieb mbj...@y7mail.com:
> I got this in a mailing list for a FOSS package that I use:
> 
> "Another thing to note when running old code on 64-bit platforms is to
> inspect the struct definitions that are used directly to store or read
> binary data. There's no standard way to guarantee compatibility but
> gcc has a "packed" pragma which should do the right thing combined
> with explicit padding where needed,"
> 
> Is this a problem, that different word lengths can screw up 
> structures?  Can unsigned int, for example, change length going from
> a 32-bit system to 64?

Yes, but that isn't the issue that the note you quoted is referring to.

Structs can include padding -- that is, unused storage that just fills in space so that the struct is a certain size (such as a multiple of 4 or 8 bytes) or that makes the struct members start on certain boundaries (such as 4 or 8 byte boundaries).

It might well be the case that on a 32-bit architecture, each struct member starts on a 4-byte boundary while on a 64-bit architecture, each struct member starts on an 8-byte boundary.

The pragma "packed" referred to in the note removes such padding, thus packing the members in the struct as tightly as possible. That makes the struct the same on both 32-bit and 64-bit architectures, barring any changes in the size of the struct members.

[toc] | [prev] | [next] | [standalone]

#57123

mbjorn@y7mail.com wrote:
> I got this in a mailing list for a FOSS package that I use:

> "Another thing to note when running old code on 64-bit platforms is to
> inspect the struct definitions that are used directly to store or read
> binary data. There's no standard way to guarantee compatibility but
> gcc has a "packed" pragma which should do the right thing combined
> with explicit padding where needed,"

> Is this a problem, that different word lengths can screw up 
> structures?  Can unsigned int, for example, change length going from
> a 32-bit system to 64?

There are at least three potential problems.

a) The size of on int on machine A (used for writing the file)
   may differ from the size of and an int (and any other types
   not explicit about their sizes) on machine B (used for rea-
   ding the file.

b) The endianess of machine A can differ from that of machine B.
   Thus, even if all the types have the exact same sizes, what
   gets read in on B can be quite different from what has been
   written on A.

c) Structure padding: the compiler is allowed to insert as
   much padding as it likes between members of the structure.
   Even the exact same compiler could, at least in principle,
   use different amounts pf padding dependent on the settings
   of some compiler switch - thus even a program on machine A,
   compiled with different settings or with a different compiler,
   may not be able to correctly read the file written on machine
   A itself.

   gcc's 'packed' flag may help in some situations (if machine A
   and B have the same sizes for all relevamt types and the same
   endianess and both programs are cpmpiled with gcc). But then
   you've still have to consider alignment issues - members of
   such a structure may need to be written to and read from by
   using memcpy() since an attempt to access a member that is
   now badly aligned due to the 'packed' attribute any other
   way may result in a bus error.

Morale: don't attempt to store structures an binary blobs in
a file if you want to be able to read that data back with any-
thing else than the exact same program that wrote it. Learned
it the hard way nearly 20 years ago;-)

                         Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#57127

jt@toerring.de (Jens Thoms Toerring) writes:
[...]
> Morale: don't attempt to store structures an binary blobs in
> a file if you want to be able to read that data back with any-
> thing else than the exact same program that wrote it. Learned
> it the hard way nearly 20 years ago;-)

It's not *quite* that bad (though it probably doesn't hurt to assume
that it is).

It can be possible to write code that's compatible between 32-bit and
64-bit implementations *if* you pay very very close attention to how
both implementations represent data.

Typically you'll want to define a struct type that has the same layout
on both systems.

You can often allow for differences in the sizes of the predefined types
by using the fixed-size intN_t and uintN_t types.  You can allow for
alignment by laying out the struct members so that neither
implementation inserts padding between them.

If endianness is an issue, you either need to do byte-swapping on one or
both side, or define the structure using only byte arrays.  If you know
that both systems have the same endianness, you might not have to do
that.

There are plenty of binary file formats that can be accessed on multiple
different systems (the various image formats, zip files, etc.)

Of course you *can* easily shoot yourself in the foot if you're not
careful, and if you're able to control the file format, there are
substantial advantages in using some sort of plain text format.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#57128

Keith Thompson <kst-u@mib.org> wrote:
> jt@toerring.de (Jens Thoms Toerring) writes:
> [...]
> > Morale: don't attempt to store structures an binary blobs in
> > a file if you want to be able to read that data back with any-
> > thing else than the exact same program that wrote it. Learned
> > it the hard way nearly 20 years ago;-)

> It's not *quite* that bad (though it probably doesn't hurt to assume
> that it is).

> It can be possible to write code that's compatible between 32-bit and
> 64-bit implementations *if* you pay very very close attention to how
> both implementations represent data.

No arguing with that. The point I wanted to make was just
dumping some random strurture with fwrite() or similar from
memory into a file (which may appear to be a simple and
straightforward solution) and hoping to be able to read it
back again on a different system can end in lot of grief;-)

                        Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#57140

jt@toerring.de (Jens Thoms Toerring) wrote:

> Keith Thompson <kst-u@mib.org> wrote:

> > It can be possible to write code that's compatible between 32-bit and
> > 64-bit implementations *if* you pay very very close attention to how
> > both implementations represent data.
> 
> No arguing with that. The point I wanted to make was just
> dumping some random strurture with fwrite() or similar from
> memory into a file (which may appear to be a simple and
> straightforward solution) and hoping to be able to read it
> back again on a different system can end in lot of grief;-)

Yah. The real point here is, it always has done. Nothing much to do with
64-bit systems specifically. Defining a file format as a memory dump
worked on the ZX Spectrum - it hasn't since.

Richard

[toc] | [prev] | [next] | [standalone]

#57124

On 2/7/15 6:33 PM, mbjorn@y7mail.com wrote:
> I got this in a mailing list for a FOSS package that I use:
>
> "Another thing to note when running old code on 64-bit platforms is to
> inspect the struct definitions that are used directly to store or read
> binary data. There's no standard way to guarantee compatibility but
> gcc has a "packed" pragma which should do the right thing combined
> with explicit padding where needed,"
>
> Is this a problem, that different word lengths can screw up
> structures?  Can unsigned int, for example, change length going from
> a 32-bit system to 64?
>

One big issue is that the "basic" types (like int) can, and do, change 
sizes between machines.

The only truly safe way to read/write binary structures is read/write 
arrays of bytes (unsigned chars) and build the bigger values explicitly.

If you don't need to worry about endian issues (you are restricting to a 
single family of processors that keep the same endianness) then often 
you can get away with structs of exact size types (uint32_t for 
example), with explicit padding so everything is on a sizeof boundary. 
(The "packed" pragma gets around that last issue).

Before moving code that was designed for a single "size", a first step 
would be to "fix" the sizes of things, converting non-fixed size types 
to their equivalent on that system. This doesn't fix all the issues, but 
handles a lot of them.

[toc] | [prev] | [next] | [standalone]

#57129

mbjorn@y7mail.com wrote:
> I got this in a mailing list for a FOSS package that I use:
 
> "Another thing to note when running old code on 64-bit platforms is to
> inspect the struct definitions that are used directly to store or read
> binary data. There's no standard way to guarantee compatibility but
> gcc has a "packed" pragma which should do the right thing combined
> with explicit padding where needed,"
 
> Is this a problem, that different word lengths can screw up 
> structures?  Can unsigned int, for example, change length going from
> a 32-bit system to 64?

It depends on your meaning of "system".

For the usual compile-link-run methodology, it depends on the 
properties and options of the compiler. It is usual for 64 bit
systems (that is, operating systems) to be able to run 32 bit 
programs, and run them exactly the same is on 32 bit OSs.

It is usual, but not required, that compiling for a 64 bit OS
will use 64 bit pointers. Other types may or may not change size.

You might even find some 32 bit systems that have a 64 bit int.

But if you recompile a program on a different system, even if both
are 32 bit or both 64 bit, it is possible for some sizes to change
and struct data not to match up.

-- glen

[toc] | [prev] | [next] | [standalone]

#57133

On 07/02/2015 23:33, mbjorn@y7mail.com wrote:
> I got this in a mailing list for a FOSS package that I use:
>
> "Another thing to note when running old code on 64-bit platforms is to
> inspect the struct definitions that are used directly to store or read
> binary data. There's no standard way to guarantee compatibility but
> gcc has a "packed" pragma which should do the right thing combined
> with explicit padding where needed,"
>
> Is this a problem, that different word lengths can screw up
> structures?  Can unsigned int, for example, change length going from
> a 32-bit system to 64?
>

One problem I found was with code that assumed a pointer was the same 
size as an int.

On 64-bit machines, pointers will be usually be 64-bits, while ints tend 
to stay at 32-bits.

Another problem was with using unions in a struct, where things might 
not line up in the way you expected. So if a union was of ints and 
pointers and was previously four bytes, might now be eight bytes because 
an element is a pointer. This can make things go wrong if you'd made 
assumptions about how it fits in with other members and unions.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#57199

On Sat, 2015-02-07, mbjorn@y7mail.com wrote:
> I got this in a mailing list for a FOSS package that I use:
>
> "Another thing to note when running old code on 64-bit platforms is to
> inspect the struct definitions that are used directly to store or read
> binary data. There's no standard way to guarantee compatibility but
> gcc has a "packed" pragma which should do the right thing combined
> with explicit padding where needed,"
>
> Is this a problem, that different word lengths can screw up 
> structures?  Can unsigned int, for example, change length going from
> a 32-bit system to 64?

If you don't know already, you should not try it.  There's a whole
taxonomy of related problems that you'll invoke it you try it without
knowing exactly what you're doing.

In general, it's a stupid idea to pretend that a random piece of
memory maps 1:1 to some struct you've defined in your program.
I've lost weeks of my life to people who thought it was a /good/ idea.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#57201

On Sat, 07 Feb 2015 15:33:39 -0800, mbjorn wrote:

> I got this in a mailing list for a FOSS package that I use:
> 
> "Another thing to note when running old code on 64-bit platforms is to
> inspect the struct definitions that are used directly to store or read
> binary data. There's no standard way to guarantee compatibility but gcc
> has a "packed" pragma which should do the right thing combined with
> explicit padding where needed,"
> 
> Is this a problem, that different word lengths can screw up structures? 
> Can unsigned int, for example, change length going from a 32-bit system to
> 64?

It can, but systems with a 64-bit "int" are rare. There are other issues
which are far more common in practice. Such as:

1. "long" is often 32 bits on 32-bit systems and 64 bits on 64-bit systems
(although "64-bit" versions of Windows have a 32-bit long).

2. Pointers are typically 32 bits on 32-bit systems and 64 bits on 64-bit
systems (including Windows).

3. size_t is typically 32 bits on 32-bit systems and 64 bits on 64-bit
systems (including Windows). Passing an int where a size_t is expected is
usually safe (sizeof(int) <= sizeof(size_t), usually). The converse isn't
safe, and a number of standard C functions return a size_t. Converting
that to an int is likely to be safe on a 32-bit platform, but unsafe on a
64-bit platform. Unfortunately, this is all too common.

4. "double" is 64 bits on all "common" platforms, both 32-bit and 64-bit,
but its alignment may differ depending upon architecture. Meaning that a
structure declaration such as

	struct foo {
	    int a;
	    double b;
	    int c;
	};

may be 16 bytes (4+8+4) on one platform but 24 bytes (4+4+8+4+4, each int
being followed by 4 bytes of padding) on another, even if sizeof(int)==4
and sizeof(double)==8 on both. On both 32-bit and 64-bit platforms,
padding is possible but not required; padding is more likely on 64-bit
platforms than on 32-bit platforms.

[toc] | [prev] | [next] | [standalone]

#59519

An incomplete example:

struct {
     char a;
     short b;
     int c;
     long d;
     long long e;
     void *f;
} oldstruct;

struct {
     char a;
     char unused1;
     int16_t b;
     int32_t c;
     int32_t d;
     int32_t unused2;
     int64_t e;
/* wtf? you don't write pointers into a file! */
     int32_t f;
} newstruct;

[toc] | [prev] | [next] | [standalone]

#59522

On 04/03/2015 10:07 AM, Lőrinczy Zsigmond wrote:
> An incomplete example:
> 
> struct {
>      char a;
>      short b;
>      int c;
>      long d;
>      long long e;
>      void *f;
> } oldstruct;
> 
> struct {
>      char a;
>      char unused1;
>      int16_t b;
>      int32_t c;
>      int32_t d;
>      int32_t unused2;
>      int64_t e;
> /* wtf? you don't write pointers into a file! */
>      int32_t f;
> } newstruct;

Your message needs a lot more words. Your code has only a limited
ability to talk for itself, even with comments included. It would help
to explain the purposes and goals behind the design of oldstruct and
newstruct, or at least how the two struct types are intended to be
related to each other.
Whatever it is that you're trying to do, it cannot be done this way
without a precise (and therefore nonportable) specification of the sizes
of the relevant types "32-bit to 64-bit" isn't sufficient. You're
implying (I think?) that short is 16 bits, long long is 64 bits, and all
of the other types are 32 bits. unused1 and unused2 seem intended to
correspond to unnamed padding in oldstruct; padding that you apparently
don't expect to happen automatically in newstruct. This implies that you
have made some fairly detailed and highly non-portable assumptions about
where padding will occur. You need to specify those assumptions in order
to have anything worth talking about - and it would be worth talking
about only in a forum dedicated to the specific platforms where your
non-portable assumptions are valid.

[toc] | [prev] | [next] | [standalone]

#59526

On Fri, 03 Apr 2015 16:07:14 +0200, L?rinczy Zsigmond <nospam@for.me>
wrote:

>An incomplete example:

very

>struct {
>     char a;
>     short b;
>     int c;
>     long d;
>     long long e;
>     void *f;
>} oldstruct;
>
>struct {
>     char a;
>     char unused1;
>     int16_t b;
>     int32_t c;
>     int32_t d;
>     int32_t unused2;
>     int64_t e;
>/* wtf? you don't write pointers into a file! */

While that may true for your applications, others could easily have
different requirements.  Moreover, it has nothing to do with what you
posted.  It IS very common to have pointers of all kinds in a struct,
such as linked lists and binary trees..

>     int32_t f;
>} newstruct;


-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#59529

>> /* wtf? you don't write pointers into a file! */
>
> While that may true for your applications, others could easily have
> different requirements.  Moreover, it has nothing to do with what you
> posted.  It IS very common to have pointers of all kinds in a struct,
> such as linked lists and binary trees..

This thread was about data-exchange between 32-bit and 64-bit programs.
Via files. Or sockets/pipes. Or shared memory. Or messages queue.
Whatever.
The point is, neither of those is supposed to contain pointers.

About detailed explanations: real programmers are able to learn
from hints.
They might not know what "int64_t" is,
but they are perfectly able to find out.
Also it is perfectly enough to say "LP64 vs LLP64 can be a problem",
they will use google the learn what the hack that means.

[toc] | [prev] | [next] | [standalone]

#59598

On Sat, 2015-02-07, mbjorn@y7mail.com wrote:
> I got this in a mailing list for a FOSS package that I use:
>
> "Another thing to note when running old code on 64-bit platforms is to
> inspect the struct definitions that are used directly to store or read
> binary data. There's no standard way to guarantee compatibility

Except not doing that.  It's IMO so much easier to just write portable
code and not worry about what struct Foo looks like on the assembly
language level on different machines.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#59608

On Saturday, April 4, 2015 at 10:06:03 PM UTC+1, Jorgen Grahn wrote:
> On Sat, 2015-02-07, mbjorn@y7mail.com wrote:
> > I got this in a mailing list for a FOSS package that I use:
> >
> > "Another thing to note when running old code on 64-bit platforms is to
> > inspect the struct definitions that are used directly to store or read
> > binary data. There's no standard way to guarantee compatibility
> 
> Except not doing that.  It's IMO so much easier to just write portable
> code and not worry about what struct Foo looks like on the assembly
> language level on different machines.
> 
The snag is that we can reasonably store the number of employees as
a 32 bit int, in the knowledge that no company will ever have
more than 2 billion employees. But what about the number of points
in a 3D model? In a world where 32MB of memory was a lot and
the points were mostly hand-specified, 32 bits would have seemed
ample. But isn't the whole point of having 64 bit integers that
counts of some things can go very high?

[toc] | [prev] | [next] | [standalone]

#59901

On Sun, 2015-04-05, Malcolm McLean wrote:
> On Saturday, April 4, 2015 at 10:06:03 PM UTC+1, Jorgen Grahn wrote:
>> On Sat, 2015-02-07, mbjorn@y7mail.com wrote:
>> > I got this in a mailing list for a FOSS package that I use:
>> >
>> > "Another thing to note when running old code on 64-bit platforms is to
>> > inspect the struct definitions that are used directly to store or read
>> > binary data. There's no standard way to guarantee compatibility
>> 
>> Except not doing that.  It's IMO so much easier to just write portable
>> code and not worry about what struct Foo looks like on the assembly
>> language level on different machines.
>> 
> The snag is that we can reasonably store the number of employees as
> a 32 bit int, in the knowledge that no company will ever have
> more than 2 billion employees. But what about the number of points
> in a 3D model? In a world where 32MB of memory was a lot and
> the points were mostly hand-specified, 32 bits would have seemed
> ample. But isn't the whole point of having 64 bit integers that
> counts of some things can go very high?

We seem to be talking about different things. By "not doing that" I
meant "not pretending to know what struct Foo looks like on the
assembly language level".  Define a data format in terms of octets,
and write packing/unpacking functions.

I have nothing against 64-bit integers, and use them myself,
frequently.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#59903

On Saturday, April 11, 2015 at 5:19:38 AM UTC+1, Jorgen Grahn wrote:
> On Sun, 2015-04-05, Malcolm McLean wrote:
> > On Saturday, April 4, 2015 at 10:06:03 PM UTC+1, Jorgen Grahn wrote:
> >> On Sat, 2015-02-07, mbjorn@y7mail.com wrote:
> >> > I got this in a mailing list for a FOSS package that I use:
> >> >
> >> > "Another thing to note when running old code on 64-bit platforms is to
> >> > inspect the struct definitions that are used directly to store or read
> >> > binary data. There's no standard way to guarantee compatibility
> >> 
> >> Except not doing that.  It's IMO so much easier to just write portable
> >> code and not worry about what struct Foo looks like on the assembly
> >> language level on different machines.
> >> 
> > The snag is that we can reasonably store the number of employees as
> > a 32 bit int, in the knowledge that no company will ever have
> > more than 2 billion employees. But what about the number of points
> > in a 3D model? In a world where 32MB of memory was a lot and
> > the points were mostly hand-specified, 32 bits would have seemed
> > ample. But isn't the whole point of having 64 bit integers that
> > counts of some things can go very high?
> 
> We seem to be talking about different things. By "not doing that" I
> meant "not pretending to know what struct Foo looks like on the
> assembly language level".  Define a data format in terms of octets,
> and write packing/unpacking functions.
> 
> I have nothing against 64-bit integers, and use them myself,
> frequently.
> 
So how would you define your binary data format for a 3D model
consisting of (for simplicity) an array of 3D points?
 

[toc] | [prev] | [next] | [standalone]

#59906

On 4/11/15 2:53 AM, Malcolm McLean wrote:

> So how would you define your binary data format for a 3D model
> consisting of (for simplicity) an array of 3D points?
>
>

The key aspect of defining *portable* data formats is to define it on a 
byte by byte basis, and the portable i/o routines break down/assemble 
pieces into/from bytes.

This does make the assumption that your system is using 8 bit bytes, but 
this is common enough that few people recommend breaking storage formats 
into bits, it just says that 9 bit storage unit systems have a wasted 
bit in each unit. You also tend to make the assumption that (signed) 
values stored are stored as two's complement without padding bits, on 
strange machines you may need to deal with this sort of issue.

If your format needs to store "reals" (floats or doubles), then you also 
need to define what representation those are in, and machines who use 
something different will need to convert to their native format to 
process the numbers. You may want use a union of the real type and an 
array of bytes to help do the conversion (even if only to correct for 
endian issues). Today, I would likely use an IEEE format for reals, but 
be aware that not all machines even today use this format.

The smart format designer would pick a data format that aligns well with 
one of the principle machines that will use the format, allowing 
machines similar enough to that one to trade off portability for 
efficiency and directly read multi-byte values or even whole structures. 
Ideally such code would use conditional compilation to automatically 
select between the portable version and the more efficient version.

For your specific example, the portable way to read an array is to loop 
over the size of the array, calling a function to read the object. The 
portable way to read an object is to call the various functions to read 
the members of the object. The portable way to read a multi-byte value 
is to read the bytes into an array, and build the value from the array.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web