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 11:09:35 -0600
- Subject: RE: gcc 3.4.2 + fpack-struct + hash_map
- References: <6.2.1.2.2.20050323095929.021e6070@iplan-mn.corp.adobe.com><200503231647.j2NGlfPZ002441@inbound-smtp-2.corp.adobe.com>
Hi Thierry,
>In our case, pack structures are used for network packet decoding and the choice was made to pack structure to make it simple and avoid errors.
Then if I were working on your QUICK-AND-DIRTY project, I'd instrument the code with the GCC __attribute__((packed)) on the network packet structures, and nothing else. That would be the quick-and-dirty fix.
I stand by my earlier general advice to NOT pack those structures, and rather to make binary-format-savvy read/write routines.
But this is "quick and dirty".
>So actually, I am rather looking for a work-around (or some backward compatibility feature in gcc?).
You may need to rebuild the Standard C++ Library with pack turned on, since you are being indiscriminate with what is/isn't packed.
I presume you are using Intel based Linux, because other Linux platforms may or may not work with packed structures.
There is a non-trivial performance penalty with using packed structures, even on Intel architecture.
However, see next...
>Using the fpack-struct on this project would just be a way to get a running version of my program in short time (no code changes, no specific tests)..
I think that -fpack-struct will cause you more grief than my suggestion above to instrument the code's network packet structs.
>...and have my boss happy to migrate to the linux world ;-).
Can't argue with that. :-)
Sincerely,
--Eljay