Need help using gcc in command line mode.

Need help using gcc in command line mode.

[Gene Creighton]

Greetings,

I recently decided to install Ubuntu Version 9.10 on a new computer 
and the installation came with gcc Version 4.4.1.  I began moving a 
number of programs that I have written over the years in "C" from my 
old computer that runs Windows XP.  I have written all of my programs 
under the command line (DOS) window.  I want to move them all to the 
new computer and compile them to run under Ubuntu.  Several of my 
programs need to read and process image data from .BMP files.   The 
first 54 bytes in a .BMP file consist of the two structures (see 
below) named WIN3XHEAD and followed immediately by 
WIN3XINFOHEAD.  The first thing that my programs do is to verify that 
the file being read is a valid .BMP file and after compiling the 
source code by gcc to run under Ubuntu, the .BMP file was flagged as 
not being a valid .BMP file.  Upon investigation, I determined that 
gcc was padding the first structure to contain 16 bytes instead of 14 
bytes and the extra two bytes of padding were located following the 
first data item, short ImageFileType.  The first two bytes that 
should belong to the next data-item, long FileSize, were being stored 
in the added 2 bytes of padding at the end of ImageFileType, and all 
remaining bytes had been moved two bytes forward from where they 
should be.  This upset not only the first structure, but the second 
structure and all of the image pixel data that follows.

I am an Electrical Engineer and spent the last 27 years of my career 
employed as a Contract Software Engineer, writing industrial software 
under contract for various Fortune 100 and 200 companies prior to 
retiring in 2003 at the age of 70 years.  I seem to recall that at 
one time I encountered a similar problem while working on a project 
for one of my clients.  I don't recall what project it was or what 
compiler or cpu I was using, but I seem to remember that there was a 
compiler option that would enable the compiler to pad arrays to 
32-byte boundaries versus 16-byte boundaries, presumably for the 
purpose of allowing faster execution times at the expense of 
increasing memory storage.  I don't recall the name of the option, 
but I suspect that this is a problem of that nature.  I have spent 
several days reading through gcc documentation but have not been able 
to determine if there is such an option in gcc.  In any case, I would 
like to know if someone can suggest a solution to this problem.  In 
the mean time, I have temporarily resolved the problem by adding 
extra code to measure the byte length of this first structure and if 
it is 16 bytes, to fill the data fields by individually reading the 
file data for each data-item within the structure.  But I am hoping 
that the discovery of an option will resolve the problem for my 
remaining programs and for future use.

Sincerely,

Gene Creighton
www.charts-is-us.com


----------

typedef struct
{
     short  ImageFileType;
     long   FileSize;
     short  Reserved1;
     short  Reserved2;
     long   ImageDataOffset;
} WIN3XHEAD;

typedef struct
{
     long   HeaderSize;
     long   ImageWidth;
     long   ImageHeight;
     short  NumberOfImagePlanes;
     short  BitsPerPixel;
     long   CompressionMethod;
     long   SizeOfBitmap;
     long   HorzResolution;
     long   VertResolution;
     long   NumColorsUsed;
     long   NumSignificantColors;
} WIN3XINFOHEAD;


----------

Re: Need help using gcc in command line mode.

[Thomas Martitz]

Am 19.12.2009 16:35, schrieb Gene Creighton:
>
> typedef struct
> {
>     short  ImageFileType;
>     long   FileSize;
>     short  Reserved1;
>     short  Reserved2;
>     long   ImageDataOffset;
> } WIN3XHEAD;
>
> typedef struct
> {
>     long   HeaderSize;
>     long   ImageWidth;
>     long   ImageHeight;
>     short  NumberOfImagePlanes;
>     short  BitsPerPixel;
>     long   CompressionMethod;
>     long   SizeOfBitmap;
>     long   HorzResolution;
>     long   VertResolution;
>     long   NumColorsUsed;
>     long   NumSignificantColors;
> } WIN3XINFOHEAD;
>
>
> ----------
>


Try appending __attribute__((packed)) after the closing } of the structs 
in question. That should disable padding.

Furthermore I recommend using int32_t instead of long, since long is 8 
bytes on 64-bit Linux systems (hence your code wouldn't work on those).

Best regards.

Re: Need help using gcc in command line mode.

[Cedric Roux]

Thomas Martitz wrote:
> Try appending __attribute__((packed)) after the closing } of the structs 
> in question. That should disable padding.
> 
> Furthermore I recommend using int32_t instead of long, since long is 8 
> bytes on 64-bit Linux systems (hence your code wouldn't work on those).
> 
> Best regards.

You can also compile with -fpack-struct
(see "man gcc")

But may I suggest that you read your file byte by byte
and feed the structures by reconstructing data with those
bytes (like "x = c1 | (c2 << 8) | (c3 << 16)" or something)?
It is the most portable solution and if your
programs don't spend all of their time in reading these
headers then there is no need to "optimize." (And you
won't waste a lot of time debugging in that direction...)

Regards,
Cédric.

Re: Need help using gcc in command line mode.

[Andrew Haley]

Cedric Roux wrote:
> Thomas Martitz wrote:
>> Try appending __attribute__((packed)) after the closing } of the structs 
>> in question. That should disable padding.
>>
>> Furthermore I recommend using int32_t instead of long, since long is 8 
>> bytes on 64-bit Linux systems (hence your code wouldn't work on those).

Yes.

> 
> You can also compile with -fpack-struct
> (see "man gcc")

No, don't.  This may break system headers.

> But may I suggest that you read your file byte by byte
> and feed the structures by reconstructing data with those
> bytes (like "x = c1 | (c2 << 8) | (c3 << 16)" or something)?
> It is the most portable solution and if your
> programs don't spend all of their time in reading these
> headers then there is no need to "optimize." (And you
> won't waste a lot of time debugging in that direction...)

All of this is good advice.

Andrew.