Mdtryhht

Coming from Casting integer constant to a pointer type

From that question, we know from 6.3.2.3p5 (C11) that we can convert any integer into a pointer (i.e. it is not UB on itself):

An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

Then, from 6.5.9p6, we have:

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.

So it seems we can apply the equality operator here with no UB (unlike the relational operators). Consider:

struct A;

int f(void) 
 struct A * a = (struct A *) 1;
 struct A * b = (struct A *) 1;
 return a == b;

Assuming there is no A object in a's address 1, one could argue that f() should return false, because no condition matches the above.

How is this refuted? Does "pointer to the same object" refer to addresses, even if no objects are there (not like the compiler could know, anyway)? Should we simply understand that it is implementation-defined since the previous results were already implementation-defined? Where does the standard specify this?

All major compilers return true for the above code, as one would expect.

How is this refuted? Does "pointer to the same object" refer to
addresses, even if no objects are there

No, I don't think that would be a plausible reading. If you stipulate that the pointer value is not a pointer to an object (and if it is not a null pointer) then an equality comparison of that (pointer) value with itself does not satisfy the "only if" condition of 6.5.9/6, and therefore the comparison must evaluate to 0.

But not so fast. Who says that (struct A *) 1 is not a pointer to an object?
Consider the Standard's definition of "object":

object

region of data storage in the execution environment, the contents of
which can represent values

(C 2011, 3.15/1)

Note that the definition is not inherently limited to objects that are allocated or declared by the program. To the best of my knowledge, the standard nowhere limits the scope of the term in that way. It does define means to allocate objects, but it does not specify that objects allocated in one of those ways are the only ones that exist. Thus, implementations are free to interpret that pointer value as a pointer to an object, in which case the equality comparison may evaluate to 1.

It also might still not evaluate to 1, as despite the two pointers (presumably) having bitwise-identical representations, they are not necessarily considered pointers to the same object.

(not like the compiler could
know, anyway)?

Of course the compiler could and should know. It has to know in order to evaluate expressions such as you present. The most straightforward approach -- and, not coincidentally, the most common -- is to interpret every non-null pointer value that is not a trap representation as a pointer to an object.

Should we simply understand that it is
implementation-defined since the previous results were already
implementation-defined?

Being implementation-defined carries a requirement for conforming implementations to document their choice. The behavior you're asking about may follow from the implementation-defined behavior of converting an integer to a pointer, but it is not implementation-defined itself.

Where does the standard specify this?

It does not specify. In principle, conforming implementations may differ on this point. In practice, however, they're pretty consistent.

Constraint violation

An integer may be converted to any pointer type. Except as previously specified, the
result is implementation-defined, might not be correctly aligned, might not point to an
entity of the referenced type, and might be a trap representation. C17dr §6.3.2.3 5

With (struct A *) 1 code attempts the conversion. The result is implementation-defined, may lack alignment, ... might be a trap.

Next code tries to initialize a below.

struct A * a = (struct A *) 1;

Initialization constraints include:

No initializer shall attempt to provide a value for an object not contained within the entity being initialized. §6.7.9 2

It is not defined that (struct A *) 1 meets that constraint.

This comparison between 2 pointers to arbitrary objects is implementation defined.

Not every architecture allow the pointers to any possible integer value. Not every architecture is able to keep a pointer that represents the location 1000 (or whatever integer), maybe because its assembly language miss such a feature. The C language does not impose any representation for a memory location -- on some architectures the address 1000 may have no meaning.

A detailed discussion is here. In this detailed explanation you can see a concrete example so:

Note that the pointers p and q point to the same memory address. Still the expression p == q evaluates to false which is very surprising at first. 

Strictly speaking, this is undefined behavior because neither a nor b point to an object and (most likely) the converted values are not properly aligned.

This however should be OK:

struct A * a = (struct A *) 1;
struct A * b = (struct A *) 1;
return (int)a == (int)b;

Since you convert an integer to a pointer and back again to get the original value.

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 a and b refer to the same (invalid) memory address i.e. 0x1

Hence they are equal. The quotation does not mean that the referred objects are equal per se, but that the memory addresses refer to the same location