Message-ID: <38B3E714.F3FC9CFE@corel.com>
Date: Wed, 23 Feb 2000 08:56:36 -0500
From: Jonathan Meunier <jonathanm AT corel DOT com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: something wierd with shorts and ints...help!
References: <38B3D5D3 DOT 35890A0 AT ozemail DOT com DOT au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 120.150.4.236
X-Trace: 23 Feb 2000 08:55:10 -0500, 120.150.4.236
Lines: 72
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Infinity da Gook wrote:
> 
> this iz prolly just a really simple thing...but i got no idea what's
> causing it....
> 
> i have a struct....
> 
> //============
> typedef struct
> {
>     byte    marker[8];    // where byte was prev defined az unsigned
> char
>     short   pad;
>     int       CatEntries;
>     int       BaseOffset;
> } TLKHeader_t;
> //==============
> 
> now when i load the data from a binary file...
> 
> 54 4C 4B 20    56 31 20 20     00 00 FA 50    00 00 76 39
> 08 00
> 
> the 'marker' array should contain this...  54 4C 4B 20 56 31 20 20
> the 'pad' should contain....  00 00
> the 'CatEntries' should contain...  FA 50 00 00
> and 'BaseOffset' ...   76 39 08 00
> 
> but it doesn't!!!
> 'marker' and 'pad' come out fine....but 'CatEntries' comes out with...
> 00 00 76 39
> 'BaseOffset' iz similarly skrewed... with   08 03 xx xx
> 
> but when i dump the struct to a file, it comez out a perfect copy of the
> original. (????)
> it seemz to me that while the struct iz read from the file properly, the
> pad (short) somehow occupies 4 bytes rather than 2 and offsets the rest
> of the struct...(??pure speculation??)

I'm not 100% sure, but I think it is due to the optimization DJGPP
does.. The data bus is 32bit, so it reads 4 bytes at a time. eg: it
would read the first 4 bytes of marker, then the next 4 bytes, then pad
*and* the next 2 bytes of CatEntries, then it would have to rotate the
bits of CatEntries 2 bytes (shl 16) and add the next 2 bytes of
CatEntries to it.. To fetch CatEntries faster, DJGPP puts 2 bytes of
padding in the struct so that it can efficiently read all the data. To
prove this, print on screen a sizeof(TLKHeader_t), it should be 20 bytes
(opposed to 18 bytes as you're expecting).

A way to fix this (and improve speed) would be to put the pad at the end
of the struct:

typedef struct
{
    byte    marker[8];
    int     CatEntries;
    int     BaseOffset;
    short   pad;
} TLKHeader_t;

If the order is more important than speed and it *must* be 18 bytes, you
can add the PACKED attribute to the struct.. not too sure how to add
this (it's something like __attribute__ _PACKED_), but I know it's in
the FAQ.

If the size of the struct doesn't really matter (eg: you were just
curious why it did that), then I'd suggest you put the short pad at the
end of the struct..

HTH,
	.(Trancelucid).
	  .  Jaune  .