www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/08/02/14:17:59

Xref: news-dnh.mv.net comp.os.msdos.djgpp:1328
Path: news-dnh.mv.net!mv!news.sprintlink.net!EU.net!i2unix!news
From: mc5686 AT mclink DOT it (Mauro Condarelli)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: GCC/DJGPP Weirdness?
Date: Wed, 02 Aug 1995 15:28:19 GMT
Lines: 65
References: <3v1t91$bjs AT alpha DOT epas DOT utoronto DOT ca>
Nntp-Posting-Host: 192.106.166.213
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

dscully AT blues DOT uucp (David Scully) wrote:

>Hi All;

>I'm new to DJGPP and have only programmed in Borland C before now.
>I've come across some unusual behavior in GCC while attempting to compile
>a program that I had written in Borland C.  Part of my program
>involved reading a Windows BMP off of disk and I had set up a structure
>to read the BMP header into.
This is a well-known problem.
gcc (and obviously djgpp) word-alignes every structure component, so that
your structure would have: sizeof(bm_header) == 15*4 == 60
Bcc would have sizeof(bmp_header) == 12*4 + 3*2 == 54
This is a BIG problem when you try to read structures which are on disk, like
your case.
Lukyly there is a way to instruct the compiler to pack the structures, it IS
ugly, bur works.
Try declaring the structure as follows:

>struct { unsigned short label			__attribute__ ((packed));
>         unsigned long total_bytes		__attribute__ ((packed));
>         unsigned long blank1			__attribute__ ((packed));
>         unsigned long first_pixel		__attribute__ ((packed));
>         unsigned long infosize		__attribute__ ((packed));
>         unsigned long width			__attribute__ ((packed));
>         unsigned long height			__attribute__ ((packed));
>         unsigned short planes			__attribute__ ((packed));
>         unsigned short bits_pixel		__attribute__ ((packed));
>         unsigned long compression		__attribute__ ((packed));
>         unsigned long size			__attribute__ ((packed));
>         unsigned long blank2			__attribute__ ((packed));
>         unsigned long blank3			__attribute__ ((packed));
>         unsigned long colours_used		__attribute__ ((packed));
>         unsigned long colours_important	__attribute__ ((packed));
>        } bmp_header;
BYW - some of the "__attribute__ ((packed))" are redundant here, but i can't
recall exactly where they go, so...

>Then I used:
>        fread(&bmp_header,54,1,in_file);
>to read the structure from the disk.  Now for some reason this doesn't
>work with DJGPP, the bytes don't end up being aligned properly after the
>read.  I discovered that  I sizeof() on the structure reveals that it is
>56 bytes long instead of 54 as declared.
56 ???
>   My question is am I trying to do something non-standard that Borland
>allowed me to get away with or is this an actual DJGPP/GCC bug and if the
>latter does anyone know a work around for this.
The problem is that internal structure representation is an internal affair
of the compiler, of course most of the times thewse representations relay
heavily on the microprocessor internal representation, so they are
interchangeable, but it is NOT guaranteed!!!
Think of it something alike the difference between "int" in bcc and "int" in
djgpp.  If you want a specific representation you have to convince the
compiler to use it, and that can be as easy as declaring "long int" or can
end up with custom I/O routines.
Your case is on the "moderately esasy" side :) :)

>        Thanks in advance,
	You're Welcome
>                          Neil Torrie
			Mauro Condarelli

Mauro Condarelli (mc5686 AT mclink DOT it)

- Raw text -


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