Is it legal to type-cast pointers of different struct types (e.g. struct sockaddr * to struct sockaddr_in6 *)?

Question

Here is a program that type-casts between pointers of type struct shape, struct rectangle and struct triangle.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

enum { RECTANGLE, TRIANGLE, MAX };

struct shape {
    int type;
};

struct rectangle {
    int type;
    int x;
    int y;
};

struct triangle {
    int type;
    int x;
    int y;
    int z;
};

struct shape *get_random_shape()
{
    int type = rand() % MAX;
    if (type == RECTANGLE) {
        struct rectangle *r = malloc(sizeof (struct rectangle));
        r->type = type;
        r->x = rand() % 10 + 1;
        r->y = rand() % 10 + 1;
        return (struct shape *) r;
    } else if (type == TRIANGLE) {
        struct triangle *t = malloc(sizeof (struct triangle));
        t->type = type;
        t->x = rand() % 10 + 1;
        t->y = rand() % 10 + 1;
        t->z = rand() % 10 + 1;
        return (struct shape *) t;
    } else {
        return NULL;
    }
}

int main()
{
    srand(time(NULL));

    struct shape *s = get_random_shape();

    if (s->type == RECTANGLE) {
        struct rectangle *r = (struct rectangle *) s;
        printf("perimeter of rectangle: %d\n", r->x + r->y);
    } else if (s->type == TRIANGLE) {
        struct triangle *t = (struct triangle *) s;
        printf("perimeter of triangle: %d\n", t->x + t->y + t->z);
    } else {
        printf("unknown shape\n");
    }

    return 0;
}

Here is the output.

$ gcc -std=c99 -Wall -Wextra -pedantic main.c
$ ./a.out 
perimeter of triangle: 22
$ ./a.out 
perimeter of triangle: 24
$ ./a.out 
perimeter of rectangle: 8

You can see above that the program compiled and ran without any warnings. I am trying to understand if it is valid to type-cast a pointer of struct shape into struct rectangle and vice-versa even though both the structs are of different sizes.

If your answer is that this is not valid, then please consider that network programming books routinely typecast between struct sockaddr *, struct sockaddr_in * and struct sockaddr_in6 * pointers depending on the socket family (AF_INET vs. AF_INET6), and then explain why such type cast is okay in case of struct sockaddr * but not in the above case of struct shape *. Here is an example of type cast with struct sockaddr *.

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>

int main()
{
    struct addrinfo *ai;

    if (getaddrinfo("localhost", "http", NULL, &ai) != 0) {
        printf("error\n");
        return EXIT_FAILURE;
    }

    if (ai->ai_family == AF_INET) {
        struct sockaddr_in *addr = (struct sockaddr_in *) ai->ai_addr;
        printf("IPv4 port: %d\n", addr->sin_port);
    } else if (ai->ai_family == AF_INET6) {
        struct sockaddr_in6 *addr = (struct sockaddr_in6 *) ai->ai_addr;
        printf("IPv6 port: %d\n", addr->sin6_port);
    }

    return 0;
}

This code compiles and runs fine as well. Moreover, this is the recommended way of writing such programs as per books on socket programming.

$ gcc -std=c99 -D_POSIX_SOURCE -Wall -Wextra -pedantic foo.c
$ ./a.out 
IPv6 port: 20480

Answer 1

The compiler would faithfully diagnose an error if the explicit type conversions were removed from

struct rectangle *r = (struct rectangle *) s;

or from

struct triangle *t = (struct triangle *) s;

The explicit type conversions, in this case, are permitted to work because what is what the standard requires. In effect, by using the explicit type conversion in these two statements you are effectively directing the compiler "shut up, I know what I'm doing".

What is more interesting is why the main() function works at run time, once you have bludgeoned the compiler into submission so it permits the conversion.

The code works because the first member of all three structs are the same type. The address of a struct is equal to the address of its first member, except that the types are different (i.e. a pointer to a struct rectangle has different type from a pointer to an int). Therefore (if we ignore the different types), the test s == &(s->type) will be true. The use of a type conversion deals with that, so (int *)s == &s->type.

Once your code has completed that test, it is then doing an explicit type conversion on s. It happens that, in the declaration

struct rectangle *r = (struct rectangle *) s;

that your code has ensured s is actually the address of a (dynamically allocated) struct rectangle. Hence the subsequent usage of r is valid. Similarly in the else if block, with a struct triangle.

The thing is, if you made an error, such as

if (s->type == RECTANGLE)
{
    struct triangle *t = (struct triangle *) s;
    printf("perimeter of triangle: %d\n", t->x + t->y + t->z);
}

(i.e. using a struct rectangle as if it is a struct triangle) then the compiler will still faithfully permit the type conversion (as discussed above). However, the behaviour is now undefined since s is not actually the address of a struct triangle. In particular, accessing t->z accesses a non-existent member.

Answer 2

Is it legal to type-cast pointers of different struct types (e.g. struct sockaddr * to struct sockaddr_in6 *)?

Yes. C explicitly provides for it:

A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer.

(C2011, 6.3.2.3/7)

As other answers have pointed out, it is not the cast itself that is the problem, but what you do with the result. And that comes down to the Strict Aliasing Rule:

An object shall have its stored value accessed only by an lvalue expression that has one of the following types:

• a type compatible with the effective type of the object,

[... plus several other alternatives that cannot apply in this case ...]

(C2011, 6.5/7; emphasis added)

The main question, therefore, is what is the effective type of the object to which the struct sockaddr * points? It's important here to understand that we can't tell from the declaration of getaddrinfo(), nor that of struct addrinfo. In particular, there is no reason to assume that the effective type is struct sockaddr.

In fact, given that the cast you've asked about is the standard and intended method for accessing the address details, there is every reason to suppose that getaddrinfo() supports that by ensuring that the effective type is the one indicated by the associated ai_family code. Then the corresponding cast yields a pointer matching the effective type of the address info. In that case, there is no problem inherent in accessing the address info via the pointer obtained via the cast.

I observe in support of the above that it is reasonable to suppose that the pointer in question points to a dynamically allocated object. The effective type of such an object depends on the means by which its stored value was last set (C2011, 6.5/6). It is not only plausible but likely that getaddrinfo() would set that value in a manner that gives it the wanted effective type. For example, code along the same lines as your shape example would do so.

Ultimately, casting the struct sockaddr * to and from pointers to the address-family-specific structs is the intended use, and there is no reason to suppose that an environment that provides getaddrinfo() would, in practice, allow those behaviors to be dubious. If it had been necessary, POSIX (by whom the function is specified) could have incorporated a special rule allowing the casts. But no such rule is needed in this case, although POSIX makes you take that on faith.

Answer 3

In the specific case of the Berkeley socket library, the POSIX standard guarantees that you can cast a pointer to a struct sockaddr_storage to a pointer to any type of socket and that the field that identifies the type of socket will map correctly.

Specifically, the POSIX standard specifies of struct sockaddr_storage:

When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol's address family.

It also says of struct sockaddr_in, “Pointers to this type shall be cast by applications to struct sockaddr * for use with socket functions.” The interface of bind(), connect() and so forth can only work if the library looks up the const struct sockaddr* it gets and figures out what type of socket it points to.

A given compiler might need magic to implement that, but this library in particular has to do it for you.

Answer 4

Your question suffers from several terminological mix-ups.

Firstly, just because your program somehow "compiled and ran without any warnings" and even produced the result you expected, it still does not mean that what you are doing in your code is somehow "valid".

Secondly, it appears that you are asking about the validity of the cast itself. In reality the cast itself is beside the point. There's are a lot of things in C that you can "typecast" to each other. However, the language makes no guarantees about what you can do with the results of such casts. The cast itself might be perfectly valid, but your further actions applied to the result might be horribly invalid.

Thirdly, and this is apparently what your question is really about: casting between pointers to different struct types that share a common initial subsequence and then accessing members from that common subsequence through the resultant pointers. It is not the cast that the issue here, it is the subsequent access. And the answer is: no, the language does not define this as a valid technique. The language allows you to inspect the common initial subsequences of different struct types united in a common union, but without a common union this is not allowed.

As for the popular technique with casts between struct sockaddr *, struct sockaddr_in * and struct sockaddr_in6 * - these are just hacks that have nothing to do with C language. They just work in practice, but as far as C language is concerned, the technique is invalid.

Answer 5

It's actually not guaranteed to work. It is guaranteed to work if the compiler sees the declaration of a union which has the three type; it is enough that the compiler sees the declaration. In that case code that accesses common leading elements of the structs is fine. Obviously the most important common element is the "type" member.

So if you have declared a union of struct shape, rectangle and triangle, you can take a pointer which does point to one of the three structs, cast the pointer, access the type field, and then go from there.

Answer 6

But this doesn't work in any language. Also in C++ you should include all the variables in the base class and declare Virtual functions in the base class. Rather to move to shape and than to rectangle , better move to void* and than to rectangle Then this is a Object oriented paradigma. Hinerhitance, polimorphimsum and other are exactly what orientate a language to the objects. To work with object in C, you should hard code. But worth it. I think that the average complexity of the programes doesn't justify to move to C++. There is the difference beetween a Ferrari and truck. At least you doesn't have to work heavy with it, C is funny. At your place I would do this:

typedef enum shape_type{
circle,
rectangle,
triangle,
//...
}S_type;

typedef struct shape
{
   S_type stype;
   int ar_par[4];//default allocated parameters number
   int* p_par; //to default it is going to contain the ar_par address
               //and you are going to change it case you needs more  parameters. You save a malloc more
   int n;//count of parameters
   int (*get_perimeter) (struct shape *);//you can also typedef them
   int (*get_area)(struct shape*);
}*Shape_ptr,Shape;

than to code such this

Shape_ptr new_rectangle(int a, int b)
{
   Shape_ptr res=malloc(sizeof(Shape));
   res->stype=rectangle;
   res->p_par=res->ar_par;//no need to allocate anything
   *res->p_par[0]=a;*res->p_par[1]=b;
   res->n=2;
   res->get_perimeter=get_rectangle_perimeter;
   res->get_area=get_rectangle_area;

}
int get_rectangle_perimeter(Shape_ptr s)
{
   return s->p_par[0]<<1 + s->p_par[1]<<1; //or multiply by two;
}
main() 
{
    Shape_ptr shp =get_random_shape() ; //this function is going to call     new_rectangle
    printf ("shap area is:%d\n",(*shp->get_area)(shp);
}

And so on... This is how you work with objects in C. Object orientated programs, contains some paradigma that in big heavy programs simplify the life of the programmer