Date: Thu, 1 Jun 2000 18:59:15 +0200 (WET)
From: Andris Pavenis <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: Gisle Vanem <giva AT bgnett DOT no>, djgpp AT delorie DOT com
Subject: Re: Inline asm: lcall & various binutils versions
In-Reply-To: <Pine.SUN.3.91.1000601162452.20285F-100000@is>
Message-ID: <Pine.A41.4.05.10006011852280.52860-100000@ieva06.lanet.lv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk



On Thu, 1 Jun 2000, Eli Zaretskii wrote:

> 
> On Thu, 1 Jun 2000, Gisle Vanem wrote:
> 
> > First 32-bit must be a linear offset and immediatially followed by 16-bit
> > for a valid selector (bigendian layout).  If gcc should optimise and align
> > '__dpmi_paddr.selector' differently it would no longer be a valid selector
> > at that address.
> 
> I don't think GCC currently makes such opimizations, does it?  16-bit 
> values should be aligned on a word boundary, so there should be no
> reason for GCC not to lay out __dpmi_paddr as you say it should be.
> 
> > What's wrong with #pragma's anyway?
> 
> They tend to change too much with compiler versions.  The `pack' pragma, 
> in particular, has a bad record of breaking DJGPP, especially in C++ 
> programs.
> 

Why? 

AFAIK
	#pragma pack(1)

	definition of some structure

	#pragma pack()

works Ok both in  C++ and C. I'm using it in my own programs (data
structures that have origin in earlier 16 bit programs where no such
padding were used).

Only thing, that perhaps it's best to keep both #pragma statements
as near as possible: best directly before and after definition of
structure.

Only time I remeber them broken were early prereleses of gcc-2.95
before middle of June 1999, but the problem were fixed
after it was reported.

Andris