Can representation and alignment be assumed for qualified types within a family

Question

I have read this post.
From that, I read this:
From C99: 6.2.7.27

A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.39) Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements. All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements. (emphasis mine)

My interpretation of the parts important to me for the purpose of this question seem to say
if I have:

int *a, **b;   

registration and alignment are guaranteed, and that all of these statements are true;

sizeof(a)==sizeof(*a)&&
sizeof(int *)==sizeof(b)&&
sizeof(*b)==sizeof(**b);// all essentially int pointers,
                        // and would be equal

but if I have:

int *a;
float*b;  

registration and alignment are not guaranteed. i.e.:

sizeof(a)!=sizeof(b)&&
sizeof(float *)!=sizeof(int *)&&
sizeof(*b)!=sizeof(*a);//all pointers, but not of compatible types
                       //therefore not guaranteed to be equal.

The reason I ask is because of this discussion,
where I posted an answer showing a function that creates a 3D array:

int *** Create3D(int p, int c, int r) 
{
    int ***arr;
    int    x,y;

    arr = calloc(p, sizeof(arr)); 
    for(x = 0; x < p; x++)
    {
        arr[x] = calloc(c ,sizeof(arr)); 
        for(y = 0; y < c; y++)
        {
            arr[x][y] = calloc(r, sizeof(int));
        }
    }
    return arr;
}

Is the following statement safe in terms of using sizeof()?

arr = calloc(p, sizeof(arr)); 

Or, even though only int types are used, should it be:

arr = calloc(p, sizeof(int **));

or:

arr = calloc(p, sizeof *arr);

The question:
Given arr is declared as int ***:
For allocating memory, as long as type stays int is there any danger of using any of the variations of int pointer (int *, int **, arr, *arr, int ***) as the argument to sizeof ?

Is one form preferred over the other? (please give reasons other than style)

Answer 1

My interpretation of the parts important to me for the purpose of this question seem to say if I have:

int *a, **b;   

registration and alignment are guaranteed,

a is a pointer to int. b is a pointer to int *. These are not compatible types, and the standard does not require pointers to these types to have the same representation or alignment.

and that all of these statements are true[:]

sizeof(a)==sizeof(*a)&&
sizeof(int *)==sizeof(b)&&
sizeof(*b)==sizeof(**b);// all essentially int pointers,
                        // and would be equal

No, the standard does not require any of those to be true. The first is frequently false on 64-bit systems. The others are typically true, but if you're looking for guarantees then the standard does not offer them.

but if I have:

int *a;
float*b;  

registration and alignment are not guaranteed. i.e.:

Correct, the representations and alignment of float * and int * are not guaranteed to be the same.

The reason I ask is because of this discussion, where I posted an answer showing a function that creates a 3D array: [..] int ***arr; int x,y;

    arr = calloc(p, sizeof(arr)); 

That will often work as intended because on most systems, all object pointers in fact do have the same size, but C does not require it to be correct. It should be:

    arr = calloc(p, sizeof(*arr));

or

    arr = calloc(p, sizeof(int **));

Likewise, this:

        arr[x] = calloc(c ,sizeof(arr)); 

should be

    arr[x] = calloc(c ,sizeof(*arr[x])); 

or

    arr[x] = calloc(c ,sizeof(int *)); 

. This one is ok, though:

            arr[x][y] = calloc(r, sizeof(int));

For allocating memory, and as long as type stays int, in that statement, is there any danger of using any variation of int pointer (int *, int **, arr, *arr) as the argument to sizeof ?

Yes. Given any type T, T * is a different, incompatible type. Regardless of qualification or pointerness, the standard provides no guarantee that the two have the same representation or alignment. Part of not having a guarantee of the same representation is not having a guarantee of the same size. In particular, if T is int then there are common cases in which T and T * have different size.

Is one form preferred over the other? (please give reasons other than style)

Although it's arguable whether this is a point of style, this form:

arr = calloc(p, sizeof(*arr));

has the advantage that if you change the type of arr, you don't have to modify the calloc call. The correct size follows from the declaration of arr. It's also easy to tell that the size is right, without looking up the declaration of arr. And it's easy to write a macro around that form if you should wish to do so.

Answer 2

Consider a fantasy compiler that only makes pointers as wide as needed.

Code uses a large set (trillions) of int and only a small set (2) of int *.

int *ticket = malloc(sizeof *ticket * 1000ULL*1000*1000*1000);
int **purchase = malloc(sizeof *purchase * 2);

Pointer arithmetic need only work within the range + 1 of the allocated memory. Pointers to int need to have have precision of 39+ bits. Pointers to int * need only have 2+ bits. Such a compiler could maintain the base of all int in code, somewhere, and add the a scaled 39 bit pointer when needed to form the physical address. Pointers to int * could use their fews bits along with a hidden in code base and scale to produce the physical address of the int *.

This is a reason for casting to void * on printf("%p", (void *) ptr) as such a compiler would need to put together the base and scale to form a generic void * pointer which could point to any object in memory. It is also a reason why casting (int **)((void *)ticket) is UB.

Similar systems existed in DOS segment:offset days with the functions in one address space (being 32 or 16 bit) and data in another address space (being independent from code 32 or 16 bit).

Present data embedded processors sometimes use one pointer size for constant data and another size for variable data.

C supports many architectures, not only the flat model of a 64-bit pointer that can point anywhere.