Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Reading from different union members

Reply
Thread Tools

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!?

Any hints, please? Thanks!
 
Reply With Quote
 
 
 
 
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

>Then, i read


read where?

> 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!?
>
> Any hints, please? Thanks!


 
Reply With Quote
 
 
 
 
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.
 
Reply With Quote
 
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.
 
Reply With Quote
 
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).

 
Reply With Quote
 
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

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 Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type? John Reye C Programming 28 05-08-2012 12:24 AM
Splitting union members in different struct pozz C Programming 2 04-15-2011 07:01 AM
Address of union members Denis Remezov C++ 6 07-01-2004 12:35 AM
union in struct without union name Peter Dunker C Programming 2 04-26-2004 07:23 PM
map XML union to C union (and vice-versa) Matt Garman XML 1 04-25-2004 12:40 AM



Advertisments