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)