writing portable code for structures 
Author Message
 writing portable code for structures

Hi, can someone please provide references or an explanation of how to define
(potentially nested) structures such that their size and element offsets are portable,
say for Windows, Linux, and Solaris?

For example, would it be enough to manually pad to force alignment and overall size
to 8 byte boundaries, e.g. (assuming I know int is 4 bytes, short is 2, and char is 1)

struct {
   int a;
   unsigned char unused1[4];
   double b;

Quote:
} foo;

and

struct {
  int a;
  short b;
  unsigned char unused1[2];
  int c;
  unsigned char unused2[2];

Quote:
}

If I defined the structures as above, wouldn't overall size and offset be assured,
independent of compiler switches (at least for "common" compilers)?

Thanks,
Matt



Tue, 07 Jun 2005 05:27:34 GMT  
 writing portable code for structures

Quote:

> Hi, can someone please provide references or an explanation of how to define
> (potentially nested) structures such that their size and element offsets are portable,
> say for Windows, Linux, and Solaris?

AFAIK, there is no way to do this in ANSI C. If you intend to share
serialized structures (e.g., written to a file in binary format) between
architectures, platforms, or applications compiled with different
compilers, you need to put them in a format which can be translated back
and forth such as XML, key=value pairs, or octets with a defined byte
order for multi-byte values.

OTOH, some compilers have special options to force the word alignment to
1 byte offsets. This is not topical on clc, and you still have to
consider endianness, but it may suit your particular application domain.

        david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
                                -- unknown



Tue, 07 Jun 2005 05:46:55 GMT  
 writing portable code for structures

Quote:

> Hi, can someone please provide references or an explanation of how to
> define (potentially nested) structures such that their size and
> element offsets are portable, say for Windows, Linux, and Solaris?

> For example, would it be enough to manually pad to force alignment and
> overall size to 8 byte boundaries, e.g. (assuming I know int is 4
> bytes, short is 2, and char is 1)

> struct {
>    int a;
>    unsigned char unused1[4];
>    double b;
> } foo;

> and

> struct {
>   int a;
>   short b;
>   unsigned char unused1[2];
>   int c;
>   unsigned char unused2[2];
> }

If you only need to do it for a few systems on which you know this data
layout stuff, then you could pick types with a known size with a #define or
a typedef ("#define FOURBYTEINT long", "typedef long FOURBYTEINT") and use
such macros/types. You could use the preprocessor to determine the actual
machine (like with the compiler model macros) because different types could
have the needed size.

- Show quoted text -

Quote:
> If I defined the structures as above, wouldn't overall size and offset
> be assured, independent of compiler switches (at least for "common"
> compilers)?

> Thanks,
> Matt



Tue, 07 Jun 2005 06:02:05 GMT  
 writing portable code for structures

Quote:

> Hi, can someone please provide references or an explanation of how
> to define (potentially nested) structures such that their size and
> element offsets are portable,

It's not possible in a portable way.

Quote:
> say for Windows, Linux, and Solaris?

Well, that contradicts portability. :)  It might be possible if you
are willing to restrict yourself to the same compiler and "similar"
hardware platforms (e.g., all three OSes on 32bit hardware, or all
three on 64bit hardware), but all such attempts are inherently non-
portable (and therefore off-topic in clc).

Quote:
> If I defined the structures as above, wouldn't overall size and
> offset be assured, independent of compiler switches (at least for
> "common" compilers)?

Not necessarily. Of course, it depends on the exact definition of
"common compilers".

May I humbly suggest that you rethink your strategy? You can avoid
a lot of hassle and dependance on specific compilers if you write
your program in such a way that it does not depend on the memory
layout of structures.

Martin



Tue, 07 Jun 2005 06:08:57 GMT  
 writing portable code for structures


Quote:
> Hi, can someone please provide references or an explanation of how to
define
> (potentially nested) structures such that their size and element offsets
are portable,
> say for Windows, Linux, and Solaris?

(snip)

If you really want it to be portable, look up XDR.  There are RFC's about
it, and the code is public domain.  It is related to Sun's RPC, and usually
documented in RPC books.

If you know the sizes of the elements, and you place them from longest
(hopefully most restrictive alignment) to shortest (less restrictive) they
should come out without padding.

You do assume that they are all the same size and endianness, which is not a
portable assumption.

-- glen



Tue, 07 Jun 2005 06:22:07 GMT  
 writing portable code for structures
Sorry, let me rephrase this in a hypothetical, albeit impractical way.

Suppose I were writing a C interpreter, and I wanted to publish a
spec whereby the C interpreter would know the alignment of structures
if programmers conformed to that spec (e.g. by manually padding the
structures as the spec directed).  And I want the guidelines to work
on "common platforms" with "common compilers".  Are there any
general rules of thumb that would facilitate the writing of such a spec?

Thanks,
Matt

Quote:


> > Hi, can someone please provide references or an explanation of how
> > to define (potentially nested) structures such that their size and
> > element offsets are portable,

> It's not possible in a portable way.

> > say for Windows, Linux, and Solaris?

> Well, that contradicts portability. :)  It might be possible if you
> are willing to restrict yourself to the same compiler and "similar"
> hardware platforms (e.g., all three OSes on 32bit hardware, or all
> three on 64bit hardware), but all such attempts are inherently non-
> portable (and therefore off-topic in clc).

> > If I defined the structures as above, wouldn't overall size and
> > offset be assured, independent of compiler switches (at least for
> > "common" compilers)?

> Not necessarily. Of course, it depends on the exact definition of
> "common compilers".

> May I humbly suggest that you rethink your strategy? You can avoid
> a lot of hassle and dependance on specific compilers if you write
> your program in such a way that it does not depend on the memory
> layout of structures.

> Martin



Tue, 07 Jun 2005 06:48:42 GMT  
 writing portable code for structures

Quote:

> Sorry, let me rephrase this in a hypothetical, albeit impractical way.

> Suppose I were writing a C interpreter, and I wanted to publish a
> spec whereby the C interpreter would know the alignment of structures
> if programmers conformed to that spec (e.g. by manually padding the
> structures as the spec directed).  And I want the guidelines to work
> on "common platforms" with "common compilers".  Are there any
> general rules of thumb that would facilitate the writing of such a spec?

Hmm, maybe it is my limited English, but now I'm confused what you are
asking. If I understand you correctly, you want to *implement* C (or
maybe you want to hypothetically assume so for the sake of this
questions), and you want advice how you can make your C implementation
maximally compatible with existing implementations. Please ignore me
if that is not what you are asking.

A specification of (amongst other things) the memory layout of
structures is called an ABI (`application binary interface'). Often
C implementors use the same ABI on a given platform, so that code
compiled with different compilers can be linked together.

However, nothing of this is required by the C language standard, and
therefore comp.lang.c is not the right place to discuss these issues.
I recommend that you find newsgroups dedicated to programming on the
platforms you are interested in, and ask there if a C ABI exists for
that platform, what it says about the memory layout of structures, and
what compilers implement it. Then you can compare the ABIs and see
how different or similar they are.

Martin



Tue, 07 Jun 2005 08:14:36 GMT  
 writing portable code for structures

Quote:

> Hi, can someone please provide references or an explanation of how to define
> (potentially nested) structures such that their size and element offsets are portable,
> say for Windows, Linux, and Solaris?

You cannot control this without using implementation-specific features;  as
soon as you do use those, you are out of the portability game.


Tue, 07 Jun 2005 09:48:16 GMT  
 writing portable code for structures

Quote:

> Are there any general rules of thumb that would facilitate the writing of
such a
> spec?

You can assume that the compiler writer is not going to do anything
perverse - so if your architecture is little-endian you can expect C
variables to be little-endian, if 32-bit words have to be aligned on 32-bit
boundaries for efficient hardware access then you can expect structures to
to padded to the nearest boundary, etc.
However what you are trying to do is fraught with difficulty. Even assuming
you can identify all basic types, compilers often have different ideas on
how to pad structures.
The portable way of achieving what you want to do is to define a binary
format for all the structures you want to use, and then convert into C
run-time structures as needed.

eg
typedef struct
{
  int width;
  int height;
  char bitsperpixel;

Quote:
}Imageheader.

Imageheader binary format

32 bits big-endian width
32 bits big-endian height
8 bits bits-per-pixel.



Thu, 09 Jun 2005 04:43:20 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Q: Portable data files - Writing classes vs. structures

2. Principles of Writing Portable C Code

3. Writing Portable C code for various Platforms (VMS, OSF, U**X)

4. Writing portable C code

5. bytes/octets (was Re: Writing portable C code

6. Byte me : ) (Was Re: Writing portable code)

7. How to get a (>32K) portable structure?

8. How to write portable(ish) C programs?

9. Tips for writing *truly* portable C?

10. Tips for writing *truly* portable C?

11. How to write a high portable C program ?

12. Tips on writing *Truly* portable C?

 

 
Powered by phpBB® Forum Software