Does removing const from a pointer-to-const obey strict aliasing in C, and refer to the same object?

Question

Does the following code in C have defined behavior?

int main() {
    const int i = 0;
    return *(int*)(&i);
}

I ask because 6.5/7 lists "a qualified version of a type compatible with the effective type of the object" as a valid alias. But the effective type of the object is const int, and I don't think int is a qualified version of const int (although the reverse is true). Neither are int and const int compatible (6.7.3/10).

Furthermore, 6.3.2.3/2 says that you can convert pointer types by adding qualifiers, and that the resulting pointer is equal. 6.3.2.3/7 says that you can convert any two pointer types (so the cast (int*)(&i) itself is permitted). But doesn't say that the resulting pointer refers to the same object or even that it is equal. All it says is that it can be converted back to the original type (in this case const int*). That is, even if the alias is legal it's not clear to me that the standard guarantees that my pointer conversion does indeed result in a pointer that refers to i.

So, does the standard actually define the behavior of my code, and if so where is this defined?

I'm aware that the code works in practice. I have in mind a hypothetical (and bizarre) implementation on which it doesn't work. I could ask whether that implementation conforms to the standard (and if not, what part it violates), but I don't want to muddy the waters if there are other respects in which my imagined implementation fails to conform. I will describe the implementation if anyone thinks it will help them answer the question.

Filet

For the cast back into int const* the standard is clear that the result must be the identity. "Otherwise, when converted back again, the result shall compare equal to the original pointer." – Spirituous

@JensGustedt: agreed. That doesn't help my code, because my code never does cast it back to int const *. – Filet

See also #28575042 – Crescent

Answer 1

It is at least implied that it works, by §6.7.3 p5:

If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.

Note that for volatile-qualified types it says refer to, but for const-qualified types it just says modify, which implies that a non-modifying access is OK ("the exception that proves the rule").

It looks to me like you may have identified a defect in the standard, though.

Complicate

I also think this should be a defect, but on the other hand, it's implied such that we know how const variables are implemented. – Perchloride

I disagree: while the const-qualification does not make non-modifying access through type-punned expressions undefined, the effective typing rules still do: differently-qualified types are incompatible (except when determining compatibility of function types by parameters) and the rules are only relaxed in the direction of additional qualification – Kenton

@Christoph: I agree that that is a result of a strict reading of the aliasing rules, but my point is that I don't think this was the intended effect, because it would render the normative paragraph I quoted entirely moot, and does not explain why different wording was used for const- and volatile- in it. – Complicate