Jump to content
  • Advertisement
Sign in to follow this  
MrFRag

sizeof problem with DevCpp

This topic is 4864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone, maybe I'm becaming crazy, but, is it possible that, sometimes, sizeof(some structure); returns a wrong value?? (I'm using DevCpp 4.9.9.2) I'm trying to code a simple bitmap reader: typedef struct bmBITMAPHEADER { char bmType[2]; int bmSize; unsigned short bmReserved1; unsigned short bmReserved2; int bmOffset; }; .... fread(&bmHeader,sizeof(bmHeader),1,f); .... if, using the debug, i check what sizeof returns, it's 16!!!!!!! how is it possible? (char*2 + int *2 + short *2) = 1*2 + 4*2 + 2*2 = 14!! what the hell are these 2 bytes that sizeof gives me?? But even more strange is that if i write fread(&bmHeader,14,1,f); the values written in the structure are however wrong... if i read member by member, lukily, it's ok. How could all this be possible?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
byte alignment

Share this post


Link to post
Share on other sites
the compiler is padding the structure to align data on 32bit boundaries in memory. i've seen a couple threads about this recently. hopefully somebody can give a link or two, or a good description.

edit: an article by john bolton

Share this post


Link to post
Share on other sites
Its a compiler optimization...

You can disable it using "#pragma pack (1)".

I would recommend you disable it, the additional speed isn't worth the risk.

In all my projects, the first thing I write is that, since it breaks my logic if things arn't aligned properly (I'm a big fan of memcpy, and it shows, since when something doesn't work as planned, the first thing I say is.. "Ahh nutts, buffer overflow again!" ).

Share this post


Link to post
Share on other sites
Quote:
Original post by Thevenin
Its a compiler optimization...

You can disable it using "#pragma pack (1)".

I would recommend you disable it, the additional speed isn't worth the risk.

In all my projects, the first thing I write is that, since it breaks my logic if things arn't aligned properly (I'm a big fan of memcpy, and it shows, since when something doesn't work as planned, the first thing I say is.. "Ahh nutts, buffer overflow again!" ).

There really isn't any reason to do that for structures that are only kept in memory. But yes, it is necessary when you're reading structures off disk.

Share this post


Link to post
Share on other sites
I did as you suggested, and with the pragma pack(1) works perfectly :D

thanks a lot, even for the article linked... it was very intresting!

Share this post


Link to post
Share on other sites
Quote:
Original post by Catafriggm
There really isn't any reason to do that for structures that are only kept in memory. But yes, it is necessary when you're reading structures off disk.


On the contrary, you could read the elements of the structure manually off the disk, therefor its not necessary.

There are very valid reasons to use #pragma pack(1) when working with applications that manipulate memory directly. Especially internet applications.

If he is working in C, I still recommend he disable it, since allowing it will only cause him frustation, as the slight performance boost will most likey go unnoticed.


Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!