From: Endlisnis <s257m AT unb DOT ca>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Real stupid problem.
Date: Tue, 02 Mar 1999 00:19:50 -0400
Organization: BrunNet
Lines: 48
Message-ID: <36DB66E6.AE0981AA@unb.ca>
References: <36db1881 DOT 8437368 AT news DOT tudelft DOT nl>
NNTP-Posting-Host: ftnts3c17.brunnet.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.04 [en] (Win95; U)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Shadow Seeker wrote:

> struct SXM_Pat_header{
>  int pat_size;
>  char pack_type;
>  short nr_rows;
>  short pattern_data_size;
> };
>
> struct SXM_Pat_header{
>  char pat_size[4];
>  char pack_type;
>  char nr_rows[2];
>  char pattern_data_size[2];
> };
>
> These are two structures, and They should be the same size at least I
> think they should be. But DJGPP manages to call the first one a size
> of 12, and the second one (the correct size) 9.
>  Does anyone know why? And if so, how do I fix it?

    It is aligning the data on boundries to make accessing faster (an int not
on a 4-byte boundry takes *twice* as long to access as an int on a 4-byte
boundry).  To fix this use the "((__attribute__))packed" feature.  Like this:

struct SXM_Pat_header{
 int pat_size;
 char pack_type;
 short nr_rows;
 short pattern_data_size;
} ((__attribute__))packed ;

This should remedy your problem.

*twice* - The actual value depends on whether the value is in L1 or L2 or L3
cache, what type of processor you are using, and many other factors.  It is
based on the fact that a 386+ processor can only ask for 32-bit values from
RAM, and only values alligned to 4-byte boundries.  So for a misaligned
address, it needs to make 2 reads/writes.
--
     (\/) Endlisnis (\/)
          s257m AT unb DOT ca
          Endlisnis AT GeoCities DOT com
          Endlisnis AT BrunNet DOT Net
          Endlisnis AT HotMail DOT com