From:	gk_2345 AT my-deja DOT com
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Probably newbie question (fread)
Date:	Tue, 12 Oct 1999 15:36:54 GMT
Organization:	Deja.com - Before you buy.
Lines:	71
Message-ID:	<7tvkik$tdg$1@nnrp1.deja.com>
References:	<pm3A4UJ05kJa092yn AT jagor DOT srce DOT hr>
NNTP-Posting-Host:	209.138.177.70
X-Article-Creation-Date:	Tue Oct 12 15:36:54 1999 GMT
X-Http-User-Agent:	Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
X-Http-Proxy:	1.0 x22.deja.com:80 (Squid/1.1.22) for client 209.138.177.70
X-MyDeja-Info:	XMYDJUIDgk_2345
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

In article <pm3A4UJ05kJa092yn AT jagor DOT srce DOT hr>,
  vbresan AT jagor DOT srce DOT hr (Viktor Bresan) wrote:
> I have a problem with the following code.
> fread (in which I read in complete struct) doesn't act as I expect.
> If I comment that line, and uncomment all other lines with fread
> (that means if i read in struct fields one by one) i get expected
result.
> You can test the program on any bmp file.
> The same code compiled with BC++ 3.1 acts normal in both cases.

The same code acts particular to BC, not normal per se...

> What causes two different behaviors in this program?
gcc (which DJGPP uses) takes your struct definitions, and
for better performance, takes the liberty of aligning all
the members along whatever boundaries are best for your
particular processor (in the case of 486+ 4-byte alignment)

What this means is that a field in a struct may not start
immediately after the field before it, it may be padded with
extra bytes to get it to align. (This really is critical
on pentiums and higher)

Your problem isn't with fread, its that it is reading into
the space where the struct is, but the struct doesn't line
up with data. (The reason this doesn't happen with BC is
that BC doesn't align anything, one of the reasons it tends
to be slower than DJGPP on modern processors)

> Should I avoid filling complete structs with one fread?
No. fread isn't the problem. You need to use the __attribute__
macro with your DJGPP source. (It's in the info docs for gcc,
type "info gcc" and look for the section: extensions) THis
supports several directives, but the one your interested in
is packed. This will force the compiler to generate this struct
without padding, and it will then work as you intended..

So change..
> #include <stdio.h>
>
> struct BITMAPFILEHEADER
>  { unsigned short bfType;
>    unsigned long  bfSize;
>    unsigned short bfReserved1;
>    unsigned short bfReserved2;
>    unsigned long  bfOffBits;
>  };

To:

 #include <stdio.h>

#if !defined(__DJGPP__)
#define __attribute__(x) /* for borland */
#endif

 struct BITMAPFILEHEADER
  { unsigned short bfType      __attribute__ ((packed));
    unsigned long  bfSize      __attribute__ ((packed));
    unsigned short bfReserved1 __attribute__ ((packed));
    unsigned short bfReserved2 __attribute__ ((packed));
    unsigned long  bfOffBits   __attribute__ ((packed));
  };

and try it again, it will work.

Good luck, and happy hacking.


Sent via Deja.com http://www.deja.com/
Before you buy.

- Raw text -