Mail Archives: djgpp-workers/2000/07/27/18:02:25
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/ ]
- Raw text -