Velocity Reviews > Reading from different union members

# Reading from different union members

Johannes Schaub (litb)
Guest
Posts: n/a

 12-30-2009
Hello all. What makes these two codes different:

union A {
int a;
float b;
};

Let's assume int has no trap representations, and size of an int is that of
a float. Then, i read that we are allowed to do the following, and it would
not be undefined behavior:

union A a;
a.b = 3.1f;
int c = a.a;

But why is this? 6.5/7 says that we are not allowed to read the value of an
object having effective type "float" by an lvalue having type "int".

Contrary, if i do the following, some sources i read say that behavior is
undefined for the above reason. However what makes this case different?

int *pc = &a.a;
int c = *pc;

What am i missing? Is this reading from an lvalue of "an aggregate or union
type that includes one of the aforementioned types among its members"? I
can't think of a way this would be true, since the lvalue used in the above
is "a.a", and it definitely has not the type "union A", but the type "int" -
the same type that the lvalue "*pc" has - so why is the one undefined, and
the other not!?

Nick Keighley
Guest
Posts: n/a

 12-30-2009
On 30 Dec, 01:33, "Johannes Schaub (litb)" <(E-Mail Removed)>
wrote:

> Hello all. What makes these two codes different:
>
> union A {
> * int a;
> * float b;
>
> };
>
> Let's assume int has no trap representations, and size of an int is that of
> a float.

you can onlyassume this for a particular implementation

> that we are allowed to do the following, and it would
> not be undefined behavior:
>
> union A a;
> a.b = 3.1f;
> int c = a.a;

I think this is UB

> But why is this? 6.5/7 says that we are not allowed to read the value of an
> object having effective type "float" by an lvalue having type "int".

hence it's UB

> Contrary, if i do the following, some sources i read say that behavior is
> undefined for the above reason. However what makes this case different?
>
> int *pc = &a.a;
> int c = *pc;
>
> What am i missing? Is this reading from an lvalue of "an aggregate or union
> type that includes one of the aforementioned types among its members"? I
> can't think of a way this would be true, since the lvalue used in the above
> is "a.a", and it definitely has not the type "union A", but the type "int" -
> the same type that the lvalue "*pc" has - so why is the one undefined, and
> the other not!?
>

Kaz Kylheku
Guest
Posts: n/a

 12-31-2009
On 2009-12-30, Johannes Schaub (litb) <(E-Mail Removed)> wrote:
> Hello all. What makes these two codes different:
>
> union A {
> int a;
> float b;
> };
>
> Let's assume int has no trap representations, and size of an int is that of
> a float. Then, i read that we are allowed to do the following, and it would

We can't make these constraining assumptions and still be talking about
the standard language at the same time.

> not be undefined behavior:
>
> union A a;
> a.b = 3.1f;
> int c = a.a;

This situation is explicitly listed in Informative Annex J of C99
(J.1 Unspecified Behavior). This points back to 6.2.6.1 (where paragraph
7 is most relevant).

However, an unspecified value may be a trap representation.
6.2.6.1/7 only tells us that the union as a whole doesn't become
a trap representation.

I.e. the above usage is not well-defined in the ISO C dialect,
though we are able to characterize specific kinds of implementations
where it will have non-failing semantics, because the unspecified
behavior is chosen such that there is no trap rep. We can expect
a certain consistency. An implementation cannot document that the
int type has no trap representation, and then fail the above a.a access.

> But why is this? 6.5/7 says that we are not allowed to read the value of an
> object having effective type "float" by an lvalue having type "int".

The effective type of the object a.a is int. a.a is declared, and for
declared objects, effective type is declared type.

6.5 doesn't resolve the union issue.

> Contrary, if i do the following, some sources i read say that behavior is
> undefined for the above reason. However what makes this case different?
>
> int *pc = &a.a;
> int c = *pc;

Nothing. This is also unspecified. This still accesses a union member,
using an lvalue which matches its effective (i.e. declared) type,
meeting the requirements of 6.5.

It is the value of a.a that is unspecified after assignment to a.b,
irrespective of how a.a is accessed.

> Is this reading from an lvalue of "an aggregate or union
> type that includes one of the aforementioned types among its members"? I

No. This is reading an int, not a union itself.

The purpose of the above text is to allow members to be manipulated
through their containing aggregates (possibly through multiple levels
of nested aggregation).

When we are, say, assigning a struct of type struct foo which contains an int
member, then you are in fact accessing that int member other than
through an lvalue of type int! The text clarifies that it is okay to
do this when the accessing lvalue is to the containing aggregate.

Ben Bacarisse
Guest
Posts: n/a

 12-31-2009
Kaz Kylheku <(E-Mail Removed)> writes:
<snip>
> However, an unspecified value may be a trap representation.

3.17.3 p2 contradicts this explicitly. I am not sure what effect that
has on the rest of your argument but I think it may be significant.

<snip>
--
Ben.

Tim Rentsch
Guest
Posts: n/a

 01-13-2010
"Johannes Schaub (litb)" <(E-Mail Removed)> writes:

> Hello all. What makes these two codes different:
>
> union A {
> int a;
> float b;
> };
>
> Let's assume int has no trap representations, and size of an int is that of
> a float. Then, i read that we are allowed to do the following, and it would
> not be undefined behavior:
>
> union A a;
> a.b = 3.1f;
> int c = a.a;
>
> But why is this? 6.5/7 says that we are not allowed to read the value of an
> object having effective type "float" by an lvalue having type "int".

The object designated by a.a has effective type "int", because 'a'
is declared as a (union A), and member 'a' of (union A) is declared
as (int).

Tim Rentsch
Guest
Posts: n/a

 01-13-2010
Kaz Kylheku <(E-Mail Removed)> writes:

> On 2009-12-30, Johannes Schaub (litb) <(E-Mail Removed)> wrote:
>> Hello all. What makes these two codes different:
>>
>> union A {
>> int a;
>> float b;
>> };
>>
>> Let's assume int has no trap representations, and size of an int is that of
>> a float. Then, i read that we are allowed to do the following, and it would

>
> We can't make these constraining assumptions and still be talking about
> the standard language at the same time.

Sure we can. The assumptions limit the set of implementations
under consideration, but it's still standard C, just not
every conceivable implementation of standard C.

>> not be undefined behavior:
>>
>> union A a;
>> a.b = 3.1f;
>> int c = a.a;

>
> This situation is explicitly listed in Informative Annex J of C99
> (J.1 Unspecified Behavior). This points back to 6.2.6.1 (where paragraph
> 7 is most relevant).

It's only the bytes that don't correspond to the object being
assigned that take unspecified values. Under the stated
assumptions there are no such bytes.

> However, an unspecified value may be a trap representation.

Again, under the assumptions stated no such trap representations
exist.

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post John Reye C Programming 28 05-08-2012 12:24 AM pozz C Programming 2 04-15-2011 07:01 AM Denis Remezov C++ 6 07-01-2004 12:35 AM Peter Dunker C Programming 2 04-26-2004 07:23 PM Matt Garman XML 1 04-25-2004 12:40 AM