RE: Why GCC do this???

[Dave Gotwisner <Dave dot Gotwisner at harmonicinc dot com>]

I mostly agree here.  If you really want the data to be portible, I wouldn't
even save it in binary.  For example, if you run a program on a sparc to
write the data using fwrite, and then read it on a PC, using fread, the bits
get all screwed up because of the endian issues involved (PCs are little
endian, sparcs are big endian).  Other architectures may have different
sizes for word and dword, and different alignment rules, etc.  You can solve
most of these by always writing in, say, big endian (using htons, htonl,
ntohs, etc.) but that won't get the alignment issues unless you write
individual items rather than the structure as a whole.

	Dave

-----Original Message-----
From: Eljay Love-Jensen [mailto:eljay@adobe.com]
Sent: Friday, May 14, 2004 6:41 AM
To: Andrea Pretto; gcc-help@gcc.gnu.org
Subject: Re: Why GCC do this???


Hi Andrea,

Claudio explained the __packed__ attribute, so I won't address that one
again.

That being said:  I *STRONGLY* recommend that you DO NOT do that.

Especially if you want your code to be platform agnostic.

If your OS or architecture changes, your code may fail.  If you COMPILER 
changes, your code may fail.  If someone adds another field in the 
structure, your code may fail.

In other words:  that coding practice is fraught with hazards!

For a canonical file format, use a byte-by-byte savvy input and output 
routine.  Do not use fread/fwrite.

If appropriate, I recommend the ntohs/ntohl for input, and htons/htonl for 
output.  Otherwise, do what you need for your custom input and output.

In your case, I assume you are using C and not C++.  In C++, you would 
encapsulate the read and write routines.

typedef struct BMP_H {
    word ID;
    dword size;
    dword res;
} BMP_H;

Note:  on 16-bit architecture, without alignment/padding, this structure is 
10 bytes.
Note:  on 32-bit architecture, without alignment/padding, this structure is 
20 bytes.
Note:  on 64-bit architecture, without alignment/padding, this structure is 
40 bytes.

Is that what you want?  Probably not.

#include <stdint.h>
typedef struct BMP_H {
    uint_least16_t ID; // Really should be char ID[2];
    uint_least32_t size;
    uint_least32_t res;
} BMP_H;

typedef char byte;
// Note:  routine does not care if char is signed or unsigned.
// Always treat byte as nonsigned (or sign indeterminate), just like char.
// This optimizes quite well.
extern byte getbyte(FILE* f); // Sets some error flag if EOF.
extern void putbyte(FILE* f, byte b); // Sets some error flag if file error.
void write_BMP_H(FILE* f, struct BMP_H* p)
{
    // Sequential "BM".  2 bytes.
    // This should have been char[2].
    // Since it's not, this is squirrelly.
    // Pretending little endian.
    p->ID = getbyte(f) & 0xFF;
    p->ID = (getbyte(f) & 0xFF) << 8;

    // Little endian size, 4 bytes.
    p->size = getbyte(f) & 0xFF
    p->size = (getbyte(f) & 0xFF) << 8;
    p->size = (getbyte(f) & 0xFF) << 16;
    p->size = (getbyte(f) & 0xFF) << 24;

    // Little endian.
    p->res = getbyte(f) & 0xFF
    p->res = (getbyte(f) & 0xFF) << 8;
    p->res = (getbyte(f) & 0xFF) << 16;
    p->res = (getbyte(f) & 0xFF) << 24;

    // Test error flag.  Yada yada yada.
}

void write_BMP_H(FILE* f, struct BMP_H* p)
{
    // Sequential "BM".  2 bytes.
    // This should have been char[2].
    // Since it's not, this is squirrelly.
    // Pretending little endian.
    putbyte(f, p->ID & 0xFF);
    putbyte(f, (p->ID >> 8) 0xFF);

    // Little endian size, 4 bytes.
    putbyte(f, p->size & 0xFF);
    putbyte(f, (p->size >> 8) & 0xFF);
    putbyte(f, (p->size >> 16) & 0xFF);
    putbyte(f, (p->size >> 24) & 0xFF);

    // Little endian.
    putbyte(f, p->res & 0xFF);
    putbyte(f, (p->res >> 8) & 0xFF);
    putbyte(f, (p->res >> 16) & 0xFF);
    putbyte(f, (p->res >> 24) & 0xFF);

    // Test error flag.  Yada yada yada.
}

You could make some helpers:
get2byte
get4byte
put2byte
put4byte

HTH,
--Eljay