Re: union {unsigned char u[10]; ...}

Yevgen Muntyan <muntyan.removethis@xxxxxxxx> writes:
Keith Thompson wrote:
Yevgen Muntyan <muntyan.removethis@xxxxxxxx> writes:
Keith Thompson wrote:
Yevgen Muntyan <muntyan.removethis@xxxxxxxx> writes:
Ben Pfaff wrote:
Yevgen Muntyan <muntyan.removethis@xxxxxxxx> writes:

Why is it legal to do

union U {unsigned char u[8]; int a;};
union U u;
u.a = 1;
u.u[0];
See C99 section 6.5 "Expressions":
An object shall have its stored value accessed only by an
lvalue expression that has one of the following types:73)
[...]
- a character type.
But character type is not a union.
[snip]

u.a is of type int. u.u[0] is of type char, a character type. The
code above accesses the stored value of the object u.a using an lvalue
expression, u.u[0], which is of character type, which satisfies 6.5.
I am not convinced. Consider this:

int a;
int b;
int *p = &b;
*(p - 1);

It accesses value of a using an lvalue of type int. The problem is
of course that *(p-1) is illegal.
Another problem is that it's not necessarily accessing the value of
a.

Well, UB here is totally enough for me, regardless of what exactly
implementation will do :)

However, the standard does explicitly allow objects to be adjacent (it
has to do so to make pointer equality work consistently). In the
absence of any knowledge of how a and b are allocated in memory,
evaluating *(p - 1) invokes undefined behavior. If you happen to know
that they're adjacent, then *(p - 1) does access the value of a, and
it's legitimate (though quite silly).

It's legitimate? Pointer arithmetic is allowed only on arrays (not sure
what correct term is, it's not those int a[2]; arrays), isn't it? I
mean, it's UB even if a and b happen to be adjacent (which itself
isn't a standard term, since standard doesn't know what it means for
objects which are not members of some aggregate, in which case we
can talk about sequences of bytes).

For purposes of pointer arithmetic, any object can be treated as if it
were a single-element array. See, for example, C99 6.5.8p4:

For the purposes of these operators, a pointer to an object that
is not an element of an array behaves the same as a pointer to the
first element of an array of length one with the type of the
object as its element type.

As for adjacency, see C99 6.5.9p6:

Two pointers compare equal if and only if both are null pointers,
both are pointers to the same object (including a pointer to an
object and a subobject at its beginning) or function, both are
pointers to one past the last element of the same array object, or
one is a pointer to one past the end of one array object and the
other is a pointer to the start of a different array object that
happens to immediately follow the first array object in the
address space.

with a footnote:

Two objects may be adjacent in memory because they are adjacent
elements of a larger array or adjacent members of a structure with
no padding between them, or because the implementation chose to
place them so, even though they are unrelated. If prior invalid
pointer operations (such as accesses outside array bounds)
produced undefined behavior, subsequent comparisons also produce
undefined behavior.

Without this special-case permission, the standard would have had to
say that, given
int a;
int b;
&a + 1 *may not* be equal to &b (or vice versa), which would require
the implementation to insert at least one byte of padding between
objects that might otherwise be adjacent.

Allowing objects to be adjacent is necessary for equality to be
defined consistently. It's for the same of implementers' convenience;
no program should take advantage of this permission.

And it's really a very minor and obscure point; you just happened to
hit on it in your example.

...
I'm not quite sure what this has to do with the question about unions,
though.

It was an example of situation where types are fine as to 6.5p7
but the expression was illegal nevertheless.

Be careful with the word "illegal". I think what you mean is that it
invokes undefined behavior.

Same thing with that union: why
is u.u access allowed, and why is value of u.u is the same as if you
actually set it, using u.u[0] = 8?
I'm afraid I don't understand what you're getting at here. u.u[0]
accesses the first byte of u.a; why would it not do so?

Because it's similar to saying

union U {int a; double b;};
U u;
int a = 1;
u.a = a;
memcpy (someplace, &u.b, 1);

is allowed and copies first byte of a. But we can't use u.b
here, or can we?

We can't use *the value of* u.b because C99 6.7.2.1p14 says:

The value of at most one of the members can be stored in a union
object at any time.

But 6.5p7 gives special permission to access an object by an lvalue
expression of character types. As the footnote there says:

The intent of this list is to specify those circumstances in which
an object may or may not be aliased.

One way to alias an object is to make it a member of a union. (Other
ways involve various pointer tricks.)

Now I'm not sure whether you can actually prove, from the wording of
the standard, that it's permitted to store a value in one member of a
union, then access a different member, as long as the other member has
character or array-of-character type. (By "permitted", I mean not
invoking undefined behavior.) But it's a reasonably common idiom, and
I'm about 95% convinced that it's *intended* to be allowed. It's
difficult to imagine an implementation that meets the requirements of
the standard but disallows this particular kind of aliasing.

I think the question of whether the wording of the standard actually
supports this conclusion is getting into comp.std.c territory.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: Warning on assigning a function-returning-a-pointer-to-arrays
    ... This declares pfunc as a function taking no arguments and returning ... int x, y; ... Presumably pfuncwill return a pointer to a single int, ... or the first of a sequence of "array 5 of int"s. ...
    (comp.lang.c)
  • Re: union {unsigned char u[10]; ...}
    ... But character type is not a union. ... has to do so to make pointer equality work consistently). ... objects which are not members of some aggregate, ... were a single-element array. ...
    (comp.lang.c)
  • Re: Newbie
    ... to talk about the int value 3 and the int value 4, ... It also lets you talk about pointer ... C has a special rule for array objects. ... to printf() is: ...
    (comp.lang.c)
  • Re: union {unsigned char u[10]; ...}
    ... But character type is not a union. ... u.a is of type int. ... has to do so to make pointer equality work consistently). ... were a single-element array. ...
    (comp.lang.c)
  • Re: How to pass a pointer to an unknown-size array?
    ... > I can pass a "pointer to a double" to a function that accepts ... > int func{ ... > Now I want to pass a pointer to an array of doubles, ...
    (comp.lang.c)
Loading