Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1373

Re: Structure Packing.

Show all headers | View raw

On 6/12/2012 3:24 PM, Walter Banks wrote:
>
>
> Martin Shobe wrote:
>
>> I don't think you understand what's being proposed.
>> (Of course, it might be my understanding that's faulty). The project is
>> to build a compiler for a system that has some strict alignment
>> restrictions, and very little RAM. As such, there isn't an issue with
>> different alignments on different systems, and the fact that those
>> asserts may fail actually helps.
>>
>> The issue I see is that the asserts in the following must not fail.
>>
>> struct s {
>>      unsigned char flag;
>>      // hole here that is exactly the right size for
>>      // an unsigned char.
>>      unsigned int value;
>> } x;
>>
>> // y has been placed by the compiler into the hole in x immediately
>> // after x.flag
>> unsigned char y;
>>
>> int main()
>> {
>>      unsigned char * hole = &x.flag + 1;
>>
>>      y = 42;
>>      *hole = 0xFF;
>>      assert(*hole == 0xFF);
>>      assert(y == 42);
>>
>>      return 0;
>> }
>
> This is the exact problem.
>
> I am less sure that pointer math in the asserts
> should be expected to reference the holes.
>
>
> The following struct illustrates the problem
> Assume that ints need to be on even boundaries
> (assume for a moment that ints are 16 bits char is 8 bits)
> the following struct will take a total of 6 bytes two are unused
>
> struct  {
>     unsigned char flag;
>     unsigned int value;
>     unsigned char flag2;
> } z;
>
> The following struct contains the same information
> but only requires 4 bytes of ram to store the
> information with no unused bytes. This is a
> change the compiler struct allocator 'could' do.
>
> struct  {
>     unsigned char flag;
>    unsigned char flag2;
>     unsigned int value;
>   } o;
>
> Compatibility is not an issue even that could be
> covered with an allocation rules pragma.
>
> I am totally convinced that using the holes for other
> globals is a bad idea.
>
> I am less convinced but very uncomfortable to
> changing a structs element order to first fit within
> a struct.

     That would make me uncomfortable, too.  Remember, it's always
allowed to convert a pointer to a struct to a pointer to its first
element and vice versa, and if your compiler rearranges the element
order this could break rather badly.  Think of all those linked
lists where the "next" pointer is assumed to be the first thing in
the struct (so "generic" functions can find it), and think of the
havoc that could ensue if the compiler silently shuffled a "double"
into first place in the name of storage efficiency ...

     One thing you might consider would be to have your compiler
emit a warning message for inefficiently-arranged structs.  (The
compiler is always permitted to whine, even about perfectly legal
code.)  This would draw people's attention to wasteful constructs
without breaking C conformance.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-06 17:27 -0700
  Re: Structure Packing. James Kuyper <jameskuyper@verizon.net> - 2012-06-06 21:19 -0400
    Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-11 22:39 -0400
      Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 09:21 -0400
        Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 11:51 -0400
          Re: Structure Packing. Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-06-12 18:37 +0200
            Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 15:06 -0400
              Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 16:22 -0400
                Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 17:44 -0400
                Re: Structure Packing. Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-06-13 15:53 +0200
                Re: Structure Packing. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-06-18 12:37 +0300
        Re: Structure Packing. Martin Shobe <martin.shobe@yahoo.com> - 2012-06-12 16:22 +0000
          Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 15:24 -0400
            Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 16:33 -0400
              Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 17:17 -0400
  Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-06 18:35 -0700
    Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-06 21:58 -0700
      Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-06 23:54 -0700
        Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-07 07:47 -0700
          Re: Structure Packing. James Kuyper <jameskuyper@verizon.net> - 2012-06-07 12:39 -0400
    Re: Structure Packing. jacob navia <jacob@spamsink.net> - 2012-06-07 11:14 +0200
      Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-07 09:46 -0700
        Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-07 11:57 -0700

csiph-web