Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: Walter Banks <walter@bytecraft.com>
Newsgroups: comp.std.c
Subject: Re: Structure Packing.
Date: Tue, 12 Jun 2012 15:24:08 -0400
Organization: Aioe.org NNTP Server
Lines: 78
Message-ID: <4FD79758.38D5CBF0@bytecraft.com>
References: <12b3df42-f6a0-4411-a5e5-136900f8255b@googlegroups.com> <jqovin$9sr$1@dont-email.me> <4FD6ABFA.72F52C75@bytecraft.com> <jr7fpp$eti$1@dont-email.me> <jr7qcu$p1u$1@dont-email.me>
NNTP-Posting-Host: uMDnRznCaHm25BLlk25agA.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD NSCPCD479  (Windows NT 5.0; U)
X-Accept-Language: en
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.std.c:1371



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.

Intetresting  problem

Walter..