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

[Yevgen Muntyan]

Hey,

Why is it legal to do

union U {unsigned char u[8]; int a;};
union U u;
u.a = 1;
u.u[0];

I tried to find it in the standard, but I only found that
value of u.u here is unspecified. Standard implies that
once u.u above is legal, then u.u[0] will be bits of first byte
u.a and so on, so here we can treat u.u in the same way as
if we did

int a = 8;
unsigned char u[sizeof a];
memcpy(u, &a, sizeof a);

But, I can't find the place which says u.u in the first
example is indeed legal and u.u value is the same as
the value of the union (which then is bytes from u.a
value, and so on).

Regards,
Yevgen

 

[Ben Pfaff]

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.

 

[Yevgen Muntyan]

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. Moreover, it actually says

- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union), or
— a character type.

i.e. character type is not in the list of types mentioned in
the above paragraph, about unions. Do I miss something here?
("aforementioned" means "listed above", right?)

Yevgen

 

[Ben Pfaff]

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.

You're accessing an object of type "int" through an object of
character type. The fact that the "int" is inside a union is
immaterial.

Moreover, it actually says

- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union), or

This gives permission for a different class of accesses, one that
in this case we're not interested in.

 

[Yevgen Muntyan]

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. Moreover, it actually says

- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union), or
— a character type.

i.e. character type is not in the list of types mentioned in
the above paragraph, about unions. Do I miss something here?
("aforementioned" means "listed above", right?)

Moreover, this paragraph is actually irrelevant. It says
you can do something like

int func (int *i);
union U {int a; double b;};
U u;
u.a = 2;
func ((int*)&u);

but it doesn't let you do

U u;
u.b = 2;
func ((int*)&u);

Same thing for character type, even if it was in the list:

you can have character array in the union, and *if* you
set this member value to representation of some double,
then you can pass the union around as it was double. But
it's not clear at all if you can set double member, and
then use the union as if you set character array member.

Yevgen

 

[Keith Thompson]

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.

Intuitively, the rules for unions imply that u.u[0] actually does
access the first byte of u.a. Rigorously proving this from the
wording of the standard may be trickier, and it's a larger task than
I'm willing to undertake at the moment.

 

[Yevgen Muntyan]

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

Intuitively, the rules for unions imply that u.u[0] actually does
access the first byte of u.a. Rigorously proving this from the
wording of the standard may be trickier, and it's a larger task than
I'm willing to undertake at the moment.

No, it's easy once you know that bytes of u.u value are the same as
bytes of value of u.

Yevgen

 

[Yevgen Muntyan]

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.

You're accessing an object of type "int" through an object of
character type.

Only when I have this object of character type. The very question
is why "u.u" yields an object of character type after u.a = 1;
(i.e. why it's not UB or constraint violation or something), and
if u.u is indeed allowed then why bytes in u.u value will be the
same as in u.a (first bytes, of course, ignoring sizes and padding
and whatnot).

I guess my question is actually this:

union U {int a; float b;};
u.a = something;

Is 'u.b' allowed here given that the bit representation of
u.a is a bit representation of a float object, and is u.b
value the same as if we did

int a = something;
float b;
memcpy (&b, &a, 4);

assuming 4 bytes int and float.

Best regards,
Yevgen

 

[Ben Pfaff]

Consider this:

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

It accesses value of a using an lvalue of type int.

No, it doesn't. It yields undefined behavior. And real
compilers are likely to put "a" into a register here, defeating
this idea in practice.

 

[Ben Pfaff]

Ben Pfaff wrote:

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.

You're accessing an object of type "int" through an object of
character type.

Only when I have this object of character type. The very question
is why "u.u" yields an object of character type after u.a = 1;
(i.e. why it's not UB or constraint violation or something), and
if u.u is indeed allowed then why bytes in u.u value will be the
same as in u.a (first bytes, of course, ignoring sizes and padding
and whatnot).

I don't really understand this question. The standard has
wording that says that u.a and u.u are at the same address, and
it has wording that says that any object may be accessed through
an lvalue of character type[*]. Put the two together, and it's
allowed.

[*] It's best to use an unsigned character type: signed character
types can have trap representations.

I guess my question is actually this:

union U {int a; float b;};
u.a = something;

Is 'u.b' allowed here given that the bit representation of
u.a is a bit representation of a float object,

No. There's a special dispensation in C99 6.5 (which we've
discussed) which allows accessing any object as an array of
characters. There's no such dispensation for aliasing an int and
a float.

and is u.b value the same as if we did

int a = something;
float b;
memcpy (&b, &a, 4);

assuming 4 bytes int and float.

No, that's a different situation: memcpy accesses objects as
arrays of characters. Thus, you can use it to do this sort of
thing and then access "b" as a float, given some additional
provisos (e.g. the bits in "a" are not a trap representation when
interpreted as float, "float" is 4 bytes long, "int" is at least
4 bytes long, ...)

 

[Keith Thompson]

Ben Pfaff wrote:

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.

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). For example:

#include <stdio.h>
int main(void)
{
int a = 42;
int b;
int *p = &b;

if (&a + 1 == &b) {
printf("Accessing a strangely: %d\n", *(p - 1));
}
else {
printf("Accessing a normally: %d\n", a);
}
return 0;
}

This program's output will be either:
Accessing a strangely: 42
or
Accessing a normally: 42
(On one implementation I tried, I got the "normally" message; swapping
the declarations of a and b got me the "strangely" message.)

If I change the two messages so they're identical, I think the program
is actually strictly conforming; the path it follows depends on
implementation-specific behavior, but the output doesn't.

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

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?

Intuitively, the rules for unions imply that u.u[0] actually does
access the first byte of u.a. Rigorously proving this from the
wording of the standard may be trickier, and it's a larger task than
I'm willing to undertake at the moment.

No, it's easy once you know that bytes of u.u value are the same as
bytes of value of u.

So what's the problem?

 

[Yevgen Muntyan]

Ben Pfaff wrote:

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.
You're accessing an object of type "int" through an object of
character type.

Only when I have this object of character type. The very question
is why "u.u" yields an object of character type after u.a = 1;
(i.e. why it's not UB or constraint violation or something), and
if u.u is indeed allowed then why bytes in u.u value will be the
same as in u.a (first bytes, of course, ignoring sizes and padding
and whatnot).

I don't really understand this question. The standard has
wording that says that u.a and u.u are at the same address,

Right here, where does the standard say u.u is an object
after you assigned u.a? I am not trying to look stupid or
pedantic, I really want to understand why you can access
member of a union other than what was assigned.
Take

union U {int a; double b;}; U u;

u.a has the same address as u.b, but you can't access
u.b after you assigned u.a (or you can but its value
is unspecified).

and
it has wording that says that any object may be accessed through
an lvalue of character type[*].

Again, this lvalue must be well-defined. In my example
with stupid pointer arithmetic we do have an lvalue of
int type, but we can't use it just because we can't
use it, not because it has wrong type.

So, once u.u is good (has the same first bytes as u, etc.)
you can use u.u to access u.a. Why is u.u "good"?

No. There's a special dispensation in C99 6.5 (which we've
discussed) which allows accessing any object as an array of
characters.

No, it's not 6.5, it's 6.2.6 that describes what happens if
you use use character arrays (in particular it says you can
use unsigned char arrays safely).
The piece of 6.5 you quoted only restricts types you can use
to access object value, it does not allow yet the very access
using those types. The obvious example is accessing unsigned
int object using int type - it may overflow.

There's no such dispensation for aliasing an int and
a float.

But double u.b isn't aliasing int u.a here. It's an expression which is
either well-defined or not. Standard says value of u.b is unspecified
here; and the paragraph about aliasing does not sound to me
as the text which explicitly makes character array members of
unions special.

Best regards,
Yevgen

 

[Old Wolf]

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.

I wonder if you can clarify something for me. The above clause does
not say that accessing a stored value via an lvalue expression of
character type is always legal. It merely says that accessing it
via other types is not legal.

Now, in N869, 6.5.2.3#5 says quite clearly that u.u can only be
accessed if it were the last member to be set, so the above code
would be UB. However the first sentence of 6.5.2.3#5 was removed
in N1124, making the above code legal again.

What did the actual C99 text say, and what did C90 have to say on the
matter?

 

[Yevgen Muntyan]

Ben Pfaff wrote:

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).

....

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.

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?

Yevgen

 

[Yevgen Muntyan]

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.

I wonder if you can clarify something for me. The above clause does
not say that accessing a stored value via an lvalue expression of
character type is always legal. It merely says that accessing it
via other types is not legal.

Now, in N869, 6.5.2.3#5 says quite clearly that u.u can only be
accessed if it were the last member to be set, so the above code
would be UB. However the first sentence of 6.5.2.3#5 was removed
in N1124, making the above code legal again.

I could only find 6.2.6.1p6 in N1124 about this business. If there are
no other restrictions, it means we can freely access any member
of union, given that we are careful with trap representations
[1]. Maybe it's in fact right, and C99 relaxed this requirement on
unions (perhaps because no implementation was stupid enough to enforce
it)? Then my question has an obvious answer.

Anyway, are you saying it's UB in C90?

[1] In particular it means that

union U {unsigned char a; unsigned char b[2];};
U u;
unsigned char foo;
u.a = 1;
foo = u.b[2];

is not UB, while

unsigned char foo;
unsigned char b;
foo = b;

is. It's kind of strange.

Thanks,
Yevgen

 

[Yevgen Muntyan]

Yevgen Muntyan wrote:
....

foo = u.b[2];

It should be u.b[1] of course.

 

[Yevgen Muntyan]

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. Moreover, it actually says

- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union), or
— a character type.

i.e. character type is not in the list of types mentioned in
the above paragraph, about unions. Do I miss something here?
("aforementioned" means "listed above", right?)

Moreover, this paragraph is actually irrelevant.

Rationale in fact confirms this, it looks like the aliasing rules
are indeed aliasing rules, they are not "what you can put into a
union"; the union mechanics is described where unions are described.
The unions mentioned there are this:

union U {int a;};
int *b;
union U *u;

here b can be used to access u.a and vice versa. It's *not* saying
that you can do this:

union U {int a; unsigned b;};
union U u;
unsigned c;
u.a = 1;
c = u.b;

If you can do it (which isn't clear), you can do it because of how
unions work, and how integer types work, not because of aliasing rules.

Yevgen

 

[Keith Thompson]

Keith Thompson wrote:
Ben Pfaff wrote:

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.

...

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.

 

[Old Wolf]

I could only find 6.2.6.1p6 in N1124 about this business. If there are
no other restrictions, it means we can freely access any member
of union, given that we are careful with trap representations

No, the aliasing rule as quoted by Ben Pfaff still applies;
you can't access a long long with a pointer to int , regardless
of whether they are in a union or not.

Anyway, are you saying it's UB in C90?

No, please re-read my post.

unsigned char foo;
unsigned char b;
foo = b;

is [UB]. It's kind of strange.

There's been some debate over whether using indeterminately
valued unsigned chars is undefined or merely unspecified. I
can't remember what the conclusion was.

 

[Yevgen Muntyan]

Keith Thompson wrote:
Ben Pfaff wrote:

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.

Sorry, I don't understand if it's yes or no. I said the following:

1) int a; int *p = &a + 1; is UB.
2) In "int a; int b;" if we say "a and b are adjacent" then it has
not meaning as far as the standard is concerned. We could talk
about implementation-specific memory layout, about what addresses
actually mean, but it's not standard.

Allowing objects to be adjacent is necessary for equality to be
defined consistently.

Standard doesn't allow nor disallow independent (as in not parts
of some aggregate) objects to be adjacent, it simply doesn't
say nor care about what it means.

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.

Nope, I hit an easy example of UB, I needed UB to demonstrate
that quoted paragraph from 6.5 wasn't enough for that union thing.
As for this example, an implementation could easily make
&a == &b + 1; (is it what's called direction in which stack grows?).

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

No, strictly speaking I mean non-strictly-conforming code.

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.

It doesn't give special permission to access union member other
than that was previously set, at least it's absolutely not obvious
if it does.

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.

Exactly, has nothing to do with this particular thing: whether
you can freely access different union members.

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,

It's also common idiom to do this:

union U {void **ptr; int **iptr;};
void func (void **ptr);
....
union U u;
u.iptr = &ip; /* ip is some int pointer */
func (u.ptr);

to avoid gcc warnings about strict aliasing when
you do just func((void*)&ip);. Similar thing is used to pass
character data around (when function takes unsigned char **
to store "any data" at given address). Or, struct hack -
common idiom, nobody knows if it's legal.

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'd think that it's simple: either you can access union members freely
(i.e. standard permits it), or not. In latter case an implementation
could explode when you do it, similar to famous implementations
which check array bounds (none does, and struct hack works).

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

I believe rationale explains the intent of that 6.5 wording, and
the intent certainly wasn't to allow accessing character array
union members. If it's allowed, then it must be elsewhere.

Best regards,
Yevgen