16 to 32 bit Data Structures

Discussion in 'C Programming' started by john, Jun 20, 2010.

  1. john

    john Guest

    I have recently started using C++ Builder and am trying to convert some
    16 bit BC 4.52 code. My problem is using 16 bit integers that have been
    stored as part of a structure in a file. When I read the entire structure
    in with Builder using an 'fread' function, Builder assumes that the
    integers are 32 bit integers and all of the data in the structure from
    this
    point is offset. This is true even if the data type is declared as 'short'
    or '__int16'.

    struct TEST
    {
    char a;
    short int b;
    long c;

    } Test;

    If this structure is written to disk using BC 4.52, it has a size of 7
    bytes. When Builder attempts to read it in, it assumes a size of 9 bytes.
    I've tried typing the short int in many different ways, but using the
    Inspect window of Builder shows that b always has a size of 4 bytes. If
    the
    structure I need to read in were actually this simple, I'd get over it by
    writing some code to position everything, but the structure I have
    contains
    over 100 elements and it would be nice if it could be read directly. Is
    this a problem with all 32 bit development platforms? Thanks for any help.
    john, Jun 20, 2010
    #1
    1. Advertising

  2. john

    Ian Collins Guest

    On 06/21/10 08:41 AM, john wrote:
    > I have recently started using C++ Builder and am trying to convert some
    > 16 bit BC 4.52 code. My problem is using 16 bit integers that have been
    > stored as part of a structure in a file. When I read the entire structure
    > in with Builder using an 'fread' function, Builder assumes that the
    > integers are 32 bit integers and all of the data in the structure from
    > this
    > point is offset. This is true even if the data type is declared as 'short'
    > or '__int16'.
    >
    > struct TEST
    > {
    > char a;
    > short int b;
    > long c;
    >
    > } Test;
    >
    > If this structure is written to disk using BC 4.52, it has a size of 7
    > bytes. When Builder attempts to read it in, it assumes a size of 9 bytes.
    > I've tried typing the short int in many different ways, but using the
    > Inspect window of Builder shows that b always has a size of 4 bytes. If
    > the
    > structure I need to read in were actually this simple, I'd get over it by
    > writing some code to position everything, but the structure I have
    > contains
    > over 100 elements and it would be nice if it could be read directly. Is
    > this a problem with all 32 bit development platforms? Thanks for any help.


    This is more of tool than a language question, the difference looks to
    be due member alignment increasing the number of padding bytes between
    members. See if you compiler has options or pragmas to force member
    packing.

    --
    Ian Collins
    Ian Collins, Jun 20, 2010
    #2
    1. Advertising

  3. john

    Eric Sosman Guest

    On 6/20/2010 4:41 PM, john wrote:
    > I have recently started using C++ Builder and am trying to convert some
    > 16 bit BC 4.52 code. My problem is using 16 bit integers that have been
    > stored as part of a structure in a file.[...]


    This is Question 2.11 (plus links) on the comp.lang.c Frequently
    Asked Questions (FAQ) page at <http://www.c-faq.com/>,

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 20, 2010
    #3
  4. On 20 June, 21:49, Ian Collins <> wrote:
    > On 06/21/10 08:41 AM, john wrote:
    >
    >
    >
    >
    >
    > >    I have recently started using C++ Builder and am trying to convert some
    > > 16 bit BC 4.52 code. My problem is using 16 bit integers that have been
    > > stored as part of a structure in a file. When I read the entire structure
    > > in with Builder using an 'fread' function, Builder assumes that the
    > > integers are 32 bit integers and all of the data in the structure from
    > > this
    > > point is offset. This is true even if the data type is declared as 'short'
    > > or '__int16'.

    >
    > > struct TEST
    > > {
    > >     char a;
    > >     short int b;
    > >     long c;

    >
    > > } Test;

    >
    > >     If this structure is written to disk using BC 4.52, it has a size of 7
    > > bytes. When Builder attempts to read it in, it assumes a size of 9 bytes.
    > > I've tried typing the short int in many different ways, but using the
    > > Inspect window of Builder shows that b always has a size of 4 bytes. If
    > > the
    > > structure I need to read in were actually this simple, I'd get over it by
    > > writing some code to position everything, but the structure I have
    > > contains
    > > over 100 elements and it would be nice if it could be read directly. Is
    > > this a problem with all 32 bit development platforms? Thanks for any help.

    >
    > This is more of tool than a language question, the difference looks to
    > be due member alignment increasing the number of padding bytes between
    > members.  See if you compiler has options or pragmas to force member
    > packing.


    or even better, don't use it. Compilers pad structs for a reason.
    Better store your data in a format that is less sensitive to such
    things.
    Nick Keighley, Jun 21, 2010
    #4
  5. john

    Ian Collins Guest

    On 06/21/10 07:43 PM, Nick Keighley wrote:
    > On 20 June, 21:49, Ian Collins<> wrote:
    >> On 06/21/10 08:41 AM, john wrote:
    >>
    >>
    >>
    >>
    >>
    >>> I have recently started using C++ Builder and am trying to convert some
    >>> 16 bit BC 4.52 code. My problem is using 16 bit integers that have been
    >>> stored as part of a structure in a file. When I read the entire structure
    >>> in with Builder using an 'fread' function, Builder assumes that the
    >>> integers are 32 bit integers and all of the data in the structure from
    >>> this
    >>> point is offset. This is true even if the data type is declared as 'short'
    >>> or '__int16'.

    >>
    >>> struct TEST
    >>> {
    >>> char a;
    >>> short int b;
    >>> long c;

    >>
    >>> } Test;

    >>
    >>> If this structure is written to disk using BC 4.52, it has a size of 7
    >>> bytes. When Builder attempts to read it in, it assumes a size of 9 bytes.
    >>> I've tried typing the short int in many different ways, but using the
    >>> Inspect window of Builder shows that b always has a size of 4 bytes. If
    >>> the
    >>> structure I need to read in were actually this simple, I'd get over it by
    >>> writing some code to position everything, but the structure I have
    >>> contains
    >>> over 100 elements and it would be nice if it could be read directly. Is
    >>> this a problem with all 32 bit development platforms? Thanks for any help.

    >>
    >> This is more of tool than a language question, the difference looks to
    >> be due member alignment increasing the number of padding bytes between
    >> members. See if you compiler has options or pragmas to force member
    >> packing.

    >
    > or even better, don't use it. Compilers pad structs for a reason.
    > Better store your data in a format that is less sensitive to such
    > things.


    Sound advice, but in this case it looks like the horse has already bolted.

    --
    Ian Collins
    Ian Collins, Jun 21, 2010
    #5
  6. john

    Nobody Guest

    On Sun, 20 Jun 2010 20:41:14 +0000, john wrote:

    > struct TEST
    > {
    > char a;
    > short int b;
    > long c;
    >
    > } Test;
    >
    > If this structure is written to disk using BC 4.52, it has a size of 7
    > bytes.


    IOW, packed (no padding).

    Modern compilers don't generally pack structures; the potential
    performance hit for unaligned access outweighs the (trivial) memory saving.

    > When Builder attempts to read it in, it assumes a size of 9 bytes.


    Odd. Most modern compilers for a 32-bit platform would use 8 bytes: one
    byte for a, one pad byte to align b to an even address, two bytes
    for b, four bytes for c. For a 64-bit platform, it could be either 8, 12
    or 16 bytes, depending upon sizeof(long) and whether a long should be
    64-bit aligned. A 32-bit platform with a 32-bit "short" would typically
    use 12 bytes (3 pad bytes between a and b).

    9 bytes suggest that "short int" is 4 bytes and that the structure is
    packed, both of which are unusual.

    > I've tried typing the short int in many different ways, but using the
    > Inspect window of Builder shows that b always has a size of 4 bytes. If
    > the
    > structure I need to read in were actually this simple, I'd get over it by
    > writing some code to position everything, but the structure I have
    > contains
    > over 100 elements and it would be nice if it could be read directly. Is
    > this a problem with all 32 bit development platforms? Thanks for any help.


    No, most 32-bit platforms will only use 8 bytes, and many will provide
    some way to pack the structure to 7 bytes.
    Nobody, Jun 21, 2010
    #6
  7. On 21 June, 09:25, Ian Collins <> wrote:
    > On 06/21/10 07:43 PM, Nick Keighley wrote:
    > > On 20 June, 21:49, Ian Collins<>  wrote:
    > >> On 06/21/10 08:41 AM, john wrote:

    >
    > >>>     I have recently started using C++ Builder and am trying to convert some
    > >>> 16 bit BC 4.52 code. My problem is using 16 bit integers that have been
    > >>> stored as part of a structure in a file. When I read the entire structure
    > >>> in with Builder using an 'fread' function, Builder assumes that the
    > >>> integers are 32 bit integers and all of the data in the structure from
    > >>> this
    > >>> point is offset. This is true even if the data type is declared as 'short'
    > >>> or '__int16'.

    >
    > >>> struct TEST
    > >>> {
    > >>>      char a;
    > >>>      short int b;
    > >>>      long c;

    >
    > >>> } Test;

    >
    > >>>      If this structure is written to disk using BC 4.52, it has a size of 7
    > >>> bytes. When Builder attempts to read it in, it assumes a size of 9 bytes.
    > >>> I've tried typing the short int in many different ways, but using the
    > >>> Inspect window of Builder shows that b always has a size of 4 bytes. If
    > >>> the
    > >>> structure I need to read in were actually this simple, I'd get over it by
    > >>> writing some code to position everything, but the structure I have
    > >>> contains
    > >>> over 100 elements and it would be nice if it could be read directly. Is
    > >>> this a problem with all 32 bit development platforms? Thanks for any help.

    >
    > >> This is more of tool than a language question, the difference looks to
    > >> be due member alignment increasing the number of padding bytes between
    > >> members.  See if you compiler has options or pragmas to force member
    > >> packing.

    >
    > > or even better, don't use it. Compilers pad structs for a reason.
    > > Better store your data in a format that is less sensitive to such
    > > things.

    >
    > Sound advice, but in this case it looks like the horse has already bolted..


    I'd still be tempted to code a reader that could read the original
    format. So read two bytes (octets) and glue them together (sorting out
    endianess) then stuff them into the struct. Yes the struct is large
    but you could code generate the struct reader somehow.

    offsetof() might be handy as well

    I'll concede progam pack might be a short term solution. But its
    inherently brittle and just stores up trouble. There are already 64
    bit machines in the world...
    Nick Keighley, Jun 22, 2010
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    1,720
    Timothy Bendfelt
    Jan 19, 2007
  2. Replies:
    4
    Views:
    1,151
  3. Alfonso Morra
    Replies:
    11
    Views:
    703
    Emmanuel Delahaye
    Sep 24, 2005
  4. Replies:
    9
    Views:
    942
    Juha Nieminen
    Aug 22, 2007
  5. Jeff.M
    Replies:
    6
    Views:
    163
    Lasse Reichstein Nielsen
    May 4, 2009
Loading...

Share This Page