delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/05/12/09:44:29

Xref: news2.mv.net comp.os.msdos.djgpp:3732
From: fnunez AT cs DOT uct DOT ac DOT za (Fabian Nunez)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Structure size
Date: 10 May 1996 07:41:07 GMT
Organization: University of Cape Town
Lines: 59
Message-ID: <4muruj$eiv@groa.uct.ac.za>
References: <3190895C DOT 41C6 AT tc0 DOT chem DOT tue DOT nl> <31929BC2 DOT 424711F9 AT alcyone DOT com>
NNTP-Posting-Host: ebi.cs.uct.ac.za
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In <31929BC2 DOT 424711F9 AT alcyone DOT com> Erik Max Francis <max AT alcyone DOT com> writes:

>Gert-Jan Schoenmakers wrote:

>> I've recently switch from Microsoft C/C++ 7.0 to djgpp 2.0 for
>> developping signal processing software. Now I have a trouble reading
>> binary data files which consist of a header and an amount of data. The
>> recent discussion about the sizeof(int) was a first step in solving the
>> problems I had (I redifined the int's to short int's) but now I'm stuck.
>> The MSC compiled program tells me sizeof(struct header)=98 and the DJGPP
>> compiled program tells me sizeof(struct header)=100.... Can someone help
>> me out on this one ????

>It's because ANSI C gives no specification on what kind of padding members of
>structures will be given.  That is to say, what you are attempting to do is
>inherently nonportable.  You should be reading in the members one at a time.

>However, there are attributes to allow you to do this in gcc; there's a bug in
>g++ 2.7.2 that won't even let this work; you'll need to use a #pragma.  Check
>the info file on gcc.

Actually, the #pragma is undocumented: it's #pragma pack. You use it like
this:

#pragma pack(1);
struct x {
	int a  __attribute__ ((packed));
	char b __attribute__ ((packed));
	float c __attribute__ ((packed));
};
#pragma pack();

The __attribute__ ((packed)) phrase forces the compiler to start each member
just after the previous one ends, instead of padding for performance
(apparently 386's and above read memory faster if the data is aligned on a 
4 byte boundary - I think I heard somewhere that 486's work best 8-aligned).
The #pragma pack phrases fix the GCC 2.7.x bug (only do this if you're
programming C++ code, the bug does not exist if you program in C). If I
remember right, you have to modify include/dir.h with the #pragma to be able
to use findfirst()/findnext() with C++.  Tiny question: why was this not
done by DJ? is doing it a bit dicey, or was it left out for forwards
compatibility? Q from a friend peering over my shoulder :) Is dir.h the only
file that needs fixing?

>If you want your code to be at all portable (which it sounds like might not be
>a bad idea, considering you're moving over from Microsoft to DJGPP), I
>recommend against this method; read in the members one at a time.

>-- 
>Erik Max Francis &tSftDotIotE && http://www.alcyone.com/max && max AT alcyone DOT com
>San Jose, California, U.S.A. && 37 20 07 N 121 53 38 W && the 4th R is respect
>H.3`S,3,P,3$S,#$Q,C`Q,3,P,3$S,#$Q,3`Q,3,P,C$Q,#(Q.#`-"C`- && 1love && folasade
>Omnia quia sunt, lumina sunt. && Dominion, GIGO, GOOGOL, Omega, Psi, Strategem
>"Out from his breast/his soul went to seek/the doom of the just." -- _Beowulf_
--
Fabian Nunez, Bachelor of Computer Science, University of Cape Town
email:fnunez AT cs DOT uct DOT ac DOT za   web:http//www.cs.uct.ac.za/~fnunez
----------------------------------------------------------------             
"k3wl aRe th3 lAmErz, 4 thEy sh4ll RulE!" - from the ElitE Bible 

- Raw text -


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