www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2004/05/02/11:54:30

X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
From: Kbwms AT aol DOT com
Message-ID: <15b.33f0137d.2dc673ae@aol.com>
Date: Sun, 2 May 2004 11:54:22 EDT
Subject: Re: pragma pack in dir.h
To: djgpp-workers AT delorie DOT com
MIME-Version: 1.0
X-Mailer: 8.0 for Windows sub 6021
Reply-To: djgpp-workers AT delorie DOT com

--part1_15b.33f0137d.2dc673ae_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 5/2/2004 9:44:05 AM Eastern Standard Time, eliz AT gnu DOT org 
writes:

> >So, what works now for GCC 3.3.3?  I'm using dir.h in an ancient program 
> >written circa 1999 and the program uses #pragma pack(1) with the comment /* 
> Kill 
> >pragmas from dir.h */.
> 
> "#pragma pack(1)" is certainly _not_ correct if it is used after
> dir.h.  Its effect is to cause GCC to pack all structs, i.e. it
> defeats the normal struc member padding meant to make member access
> aligned according to the member data width.
> 
> However, if that program has only one source file, and there are no
> struct definitions in system header files included after dir.h, you
> will not see any adverse effects (except, perhaps, some slowdown) in
> that particular program.
> 
> But for better results, you should use "#pragma pack(0)" (or patch
> your dir.h).
> 
> >Where is pragma pack(0) documented?
> 
> Unfortunately, it isn't.  The GCC manual doesn't document pragma pack
> (or i386-specific pragmas in general).
> 
> I simply guessed that pack(0) should reset the padding to its default
> state, but couldn't be sure until I googled for this and found a few
> messages posted to GCC-related forums which explained that this indeed
> is the case.
> 

Terrific, Eli.  Thank you.

--part1_15b.33f0137d.2dc673ae_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D3 PTSIZE=3D12 FAMILY=
=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">In a message dated 5/2/2004 9:44:05 A=
M Eastern Standard Time, eliz AT gnu DOT org writes:<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT><FONT  COLOR=3D"#000000"=
 BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 PTSIZE=3D10 F=
AMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">&gt;So, what works now for GCC=
 3.3.3?&nbsp; I'm using dir.h in an ancient program <BR>
&gt;written circa 1999 and the program uses #pragma pack(1) with the comment=
 /* Kill <BR>
&gt;pragmas from dir.h */.<BR>
<BR>
"#pragma pack(1)" is certainly _not_ correct if it is used after<BR>
dir.h.&nbsp; Its effect is to cause GCC to pack all structs, i.e. it<BR>
defeats the normal struc member padding meant to make member access<BR>
aligned according to the member data width.<BR>
<BR>
However, if that program has only one source file, and there are no<BR>
struct definitions in system header files included after dir.h, you<BR>
will not see any adverse effects (except, perhaps, some slowdown) in<BR>
that particular program.<BR>
<BR>
But for better results, you should use "#pragma pack(0)" (or patch<BR>
your dir.h).<BR>
<BR>
&gt;Where is pragma pack(0) documented?<BR>
<BR>
Unfortunately, it isn't.&nbsp; The GCC manual doesn't document pragma pack<B=
R>
(or i386-specific pragmas in general).<BR>
<BR>
I simply guessed that pack(0) should reset the padding to its default<BR>
state, but couldn't be sure until I googled for this and found a few<BR>
messages posted to GCC-related forums which explained that this indeed<BR>
is the case.<BR>
</BLOCKQUOTE><BR>
</FONT><FONT  COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D3 PTSIZE=3D12 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><=
BR>
Terrific, Eli.&nbsp; Thank you.</FONT></HTML>

--part1_15b.33f0137d.2dc673ae_boundary--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019