delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/05/09/16:42:23

From: kagel AT quasar DOT bloomberg DOT com
Date: Thu, 9 May 1996 16:31:50 -0400
Message-Id: <9605092031.AA05310@quasar.bloomberg.com >
To: j DOT aldrich6 AT genie DOT com
Cc: djgpp AT delorie DOT com
In-Reply-To: <199605091349.AA117349769@relay1.geis.com> (j.aldrich6@genie.com)
Subject: Re: more sizeof questions
Reply-To: kagel AT dg1 DOT bloomberg DOT com

   From: j DOT aldrich6 AT genie DOT com
   Date: Thu,  9 May 96 13:41:00 UTC 0000

   Reply to message 5683427    from KAGEL AT DG1 DOT BLO on 05/09/96  8:31AM

   >Not quite.  Actually, each field does NOT need word-alignment.  Only objects
   >whose size is >= 4 bytes (long, int, float, long long & double [did I miss
   >any?])

   long double  :)

   >require word (4byte) address alignment.  The member TotalMemory is not
   >padded as both it and the char array Info require 2byte alignment.  The extra
   >two bytes are added at the end of the structure to insure that each element of
   >an array of _VGAInfoBlock's will each have their first member, VESASignature,
   >aligned.

   That doesn't make sense.  The last time I checked, 256 was divisible by 4, so
   the struct should be word-aligned without any padding, right?  Adding 2 bytes
   would make the size 258, which is NOT aligned.


Of course 256 is divisible.  However, the pad added to the first field padded
made the size 258 requiring the 2byte pad at the end to fill ther structure out
to 260 bytes.

   BTW, there's something I meant to mention about the original post...

      >typedef unsigned char 		BYTE;
      >typedef unsigned short 	WORD;
      >typedef unsigned long		DWORD;

   This is not a good way to define WORD and DWORD - the whole reason
   that int is different sizes on different machines/compilers is that they use a
   different word size.  On a 16-bit compiler, a word is 16 bits, and on a 32-bit
   compiler, a word is 32 bits.  According to the ANSI C spec, there is no
   guarantee that any given type will be any given number of bytes, only that
   they guarantee at least a certain minimum range of values.  Heck, ANSI
   C even allows for the possibility of using one's complement negatives
   instead of two's complement, which would blow away any possibility
   of cross-compatibility between two such programs.  Not that the above
   code won't work on 99.9% of C compilers, but it's a little misleading.

Agreed.

-- 
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com

A proverb is no proverb to you 'till life has illustrated it.  -- John Keats

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019