This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.4.2 + fpack-struct + hash_map
- From: Eljay Love-Jensen <eljay at adobe dot com>
- To: Thierry MARTIN <thierry dot martin at accellent-group dot com>, gcc-help at gcc dot gnu dot org
- Date: Wed, 23 Mar 2005 10:10:10 -0600
- Subject: Re: gcc 3.4.2 + fpack-struct + hash_map
- References: <200503231554.j2NFsvPZ025925@inbound-smtp-2.corp.adobe.com>
Hi Thierry,
>I am just looking for a good advice...
My good advice is to avoid packed structures.
For those few structures that "really need to be packed", I would first ask "Why does this structure 'really need' to be packed?"
When the reason to pack the structure is compelling (and I've only seen two cases for a compelling reason: DMA required structure layout for audio data, and pixmap layout) tag the structure with the appropriate __attribute__((packed)) ... please see the GCC manual regarding the details of this compiler directive.
A reason I have heard cited -- which I consider a completely BOGUS reason -- is file format layout. In memory data structures should be constructed (marshalled) from the file format layout, and be serialized when written to the file format. That means making binary-format-savvy read and binary-format-savvy write routines. Also, employ ntoh and hton routines to help make the binary-format platform agnostic. Regardless if it is to/from a file format, or to/from over-the-wire communication.
Packed structures can be sensitive to platform constraints, and hence, make the code not portable. Tender Loving Care can help defuse this issue, but that requires a HEAVY dose of CARE.
HTH,
--Eljay