public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gene Creighton <g_creigh@siscom.net>
To: gcc-help@gcc.gnu.org
Subject: Need help using gcc in command line mode.
Date: Sat, 19 Dec 2009 17:00:00 -0000	[thread overview]
Message-ID: <1261236913_110979@mail01> (raw)

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;


----------

             reply	other threads:[~2009-12-19 15:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-19 17:00 Gene Creighton [this message]
2009-12-19 17:09 ` Thomas Martitz
2009-12-21  9:22   ` Cedric Roux
2009-12-21 17:00     ` Andrew Haley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1261236913_110979@mail01 \
    --to=g_creigh@siscom.net \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).