Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3980ADAC.5250D452@phekda.freeserve.co.uk>
Date: Thu, 27 Jul 2000 22:46:20 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Packed attribute and __dpmi_paddr
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

A while ago in comp.os.msdos.djgpp I had a discussion with Eli and several
other people (Mark, Prashant too?) about how to solve the problem of
getting lcall to compile unchanged with various versions of binutils.
Well, that seems to be impossible AFAICT, hence the detection of gas
version in Makefiles.

While looking at this problem, I noticed that lcall was calling an address
based on a __dpmi_paddr structure:

    typedef struct {
       unsigned long  offset32;
       unsigned short selector;
    } __dpmi_paddr;

I was surprised to discover that this structure did not have
__attribute__((packed)) applied to all its members. I thought all system
structures should be packed, to ensure the correct byte ordering.

According to N843 document (an almost C99?) structures can have padding
added anywhere, if my interpretation of the following paragraph is correct
- from section "6.7.2.1  Structure and union specifiers" of the N843
document:

    [#12]  Within  a structure object, the non-bit-field members
    and the units in which bit-fields reside have addresses that
    increase in the order in which they are declared.  A pointer
    to a structure object, suitably  converted,  points  to  its
    initial  member  (or  if that member is a bit-field, then to
    the unit in which it resides), and vice versa.  There may be
    unnamed  padding  within  a structure object, but not at its
    beginning.

The last sentence is the one of concern to me.

For some reason I think that gcc will only pad at the end of a structure
for alignment purposes, but it could pad in the middle, if it wanted, for
example, to align:

struct {
  char small_var;
  long big_var;
};

By inserting 3 bytes after small_var, the struct would be made
long-aligned (NB: when long occupies 4 bytes).

Finally, to my question: should all system-related (*) structures in DJGPP
headers be packed? I know this would make the headers look a bit ugly.

(*) e.g. calls to DOS, DPMI where byte-order will be important.

Thanks, bye,

-- 
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]