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

Groups > comp.lang.c > #103128

Re: lvalues from the ternary op

Show all headers | View raw

Kelsey Bjarnason <kbjarnason@gmail.com> writes:

>> [accessing a union member when a different member was the
>>  last member written]
>
> This makes me wonder...
>
> union {
>   type_1 a;
>   type_2 b;
> } u;
>
> Assume type_1 has no trap representations, while type_2 does;  or
> each does but they're different, and further assume they overlap
> such that sizeof(u) is more or less the size of the largest,
> rather than the combined size of each...

Members of a union are guaranteed to overlap, and to start at the
same address, which is the address at which the union object as
a whole starts.

> [...]
>
> I submit that the correct semantics is that any valid value of o.a
> can be stored into a, regardless of the details of o.b; and
> likewise it can be retrieved from u.a without invoking u.b's
> behaviour.

Presumably you meant u.a and u.b there rather than o.a and o.b.

> Which suggests that what counts is not "accessing the storage *of*
> an object", but, rather, accessing the storage *as* an object.  As
> long as object u.b is not accessed (without an intervening store
> of a legitimate value into u.b), then there should be no
> unexpected behaviour, the accessing of u.a should behave exactly
> as if u.a were a member of a struct, rather than a union.

How this is worded is a little funny so I'm not sure exactly
what you mean to say.  But I think we can clear things up by
looking at a slightly different example.

We start with two scalar types, which I will call Smaller and
Larger, and with sizeof (Smaller) < sizeof (Larger).  The type
Smaller has no trap representations (and more specifically, it
has one abstract value for each distinct set of bit values, so
there is a one-to-one mapping between its values and its object
representations).  Also neither of these types is a character
type.  We will leave aside for the moment the question of whether
the type Larger has any trap representations.

Now here is our union:

    union { Smaller small; Larger large; } u = { 0 };

where the initialization is done just to avoid any funny
business with uninitialized values.

Given the above, it is always okay to access u.small, in the
sense that the result will never be undefined behavior,
regardless of whether u.small or u.large was the last member
assigned to.  If u.small was the last member assigned to, reading
u.small will give the value that was assigned.  If u.large was
the last member assigned to, reading u.small will take those
bytes of u.large that occupy the same memory as the bytes of
u.small, and interpret them as an object representation of
type Smaller, and give the abstract value that corresponds to
that object representation.  Since the type Smaller has no
trap representations, the result is well-defined, although
what value comes out depends on what value was stored in
u.large, how that type is represented, etc.

Going the other direction, writing u.small and reading u.large,
what happens depends on whether the type Larger has or does not
have trap representations.  Writing u.small gives defined bit
values for the bytes that u.small occupies, and unspecified bit
values for all other bytes of u (and in particular, for those
bytes of u.large that do not correspond to the bytes of u.small).
If the defined bits plus the unspecified bits happen to be a trap
representation for type Larger, boom!, it's undefined behavior;
if they happen not to be, all is okay, and we get some abstract
value of the Larger type (which depends on the bit values and on
how different object representations map onto a Larger value).

If the type Larger does _not_ have trap representations, then
reading u.large is always okay, and is very much like the reverse
situation, except that in this case some of the bits of u.large
would be unspecified if u.small were the member last written.

The above can be shown easily as a simple picture:

   +--------+--------+--------+--------+--------+--------+--------+--------+
   |        |        |        |        |        |        |        |        |
   |        |        |        |        |        |        |        |        |
   |        |        |        |        |        |        |        |        |
   +--------+--------+--------+--------+--------+--------+--------+--------+
   <---- u.small ---->
   <------------- u.large ------------->
   <----------------------------------- u --------------------------------->

Assuming sizeof (Smaller) == 2, sizeof (Larger) == 4, and unions
are always padded to a multiple of 8 bytes.

Note that there are exactly three objects.  Storing a value into
the u.large object changes the values of the two bytes that make
up the underlying memory of the u.small object.  Storing into an
object implies changing the values of bytes in the underlying
memory.  But in the other direction, changing the values of
bytes that are (perhaps only some of) the underlying memory does
NOT imply that the other object was accessed.  An assignment like

    u.large = 7;

changes the bytes underlying the u.small object, but it is not
an access to u.small.  Which object is accessed depends on not
just what bytes are affected but what source code does the
accessing.  Does that all make sense?

If you are okay up to here, the last step is to keep the same
picture but now let the sizes of the two members be the same.  We
still have three objects, with the two member objects coinciding
in terms of what bytes they occupy.  Because the two types have
the same size, there are no unspecified bit values to think
about due to writing one member and reading another.  Thinking
about the case when the members have different sizes helps
understand the case when their sizes are the same.

Does this explanation agree with what you were trying to say?

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

Thread

Re: lvalues from the ternary op Manfred <noname@invalid.add> - 2017-01-04 19:46 +0100
  Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-04 11:08 -0800
  Re: lvalues from the ternary op Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 21:10 +0000
    Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 13:48 -0800
      Re: lvalues from the ternary op Ian Collins <ian-news@hotmail.com> - 2017-01-05 11:07 +1300
        Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 14:20 -0800
      Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-04 14:41 -0800
        Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 15:21 -0800
          Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-04 15:52 -0800
            Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 16:37 -0800
            Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 18:31 -0800
              Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 17:26 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-13 17:49 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 22:53 -0800
    Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 17:08 -0800
      Re: lvalues from the ternary op Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 02:15 +0000
        Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 22:51 -0800
      Re: lvalues from the ternary op luser droog <luser.droog@gmail.com> - 2017-01-16 23:09 -0800
        Re: lvalues from the ternary op Manfred <noname@invalid.add> - 2017-01-18 14:51 +0100
          Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-18 09:59 -0800
            Re: lvalues from the ternary op Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-01-18 13:12 -0500
            Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-18 12:11 -0800
              Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-18 12:45 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-18 14:07 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-18 14:40 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-18 16:10 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-18 18:08 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-19 06:44 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-19 08:40 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-19 12:32 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-20 06:01 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-20 08:15 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-20 10:51 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-20 11:32 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-20 13:41 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-23 07:04 -0800
                Re: lvalues from the ternary op Ike Naar <ike@iceland.freeshell.org> - 2017-01-23 17:59 +0000
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-23 10:57 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:45 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-31 09:13 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-31 10:17 -0800
                Re: lvalues from the ternary op Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-01 01:51 +0000
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-01 14:24 -0800
                Re: lvalues from the ternary op Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-02 03:07 +0000
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 04:43 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-04 08:01 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 09:06 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-09 11:56 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 10:29 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-12 13:43 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:44 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-20 08:15 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 07:58 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-24 10:00 -0800
                Re: lvalues from the ternary op scott@slp53.sl.home (Scott Lurndal) - 2017-02-24 18:58 +0000
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-24 13:03 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-02-24 14:11 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-02-24 12:42 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-02-24 13:49 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-24 13:58 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-02-24 14:56 -0800
                Re: lvalues from the ternary op supercat <flatfinger@casperkitty.com> - 2017-02-25 14:00 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 09:23 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 09:43 -0800
                Re: lvalues from the ternary op Kelsey Bjarnason <kbjarnason@gmail.com> - 2017-02-01 22:47 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-02 10:12 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 07:51 -0800
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-04 08:18 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 08:58 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 04:00 -0800
                Re: lvalues from the ternary op Kelsey Bjarnason <kbjarnason@gmail.com> - 2017-02-04 09:35 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 09:35 -0800
                Re: lvalues from the ternary op Robert Wessel <robertwessel2@yahoo.com> - 2017-01-31 13:36 -0600
                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-31 12:23 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 13:48 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:53 -0800
            Re: lvalues from the ternary op Manfred <noname@invalid.add> - 2017-01-19 14:10 +0100
        Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 12:05 -0800

csiph-web