Suppose a C library has to share the details of a structure with the application code and has to maintain API and ABI backward compatibility. It tries to do this by checking the size of the structure passed to it.

Say, the following structure needs to be updated. In library version 1,

```
typedef struct {
    int size;
    char* x;
    int y;
} foo;

```

In version 2 of the library, it is updated to:

```
typedef struct {
    int size;
    char* x;
    int y;
    int z;
} foo_2;

```

Now, library version 2 wants to check if the application is passing the new `foo_2` or the old `foo` as an argument, `arg`, to a function. It assumes that the application has set `arg.size` to `sizeof(foo)` or `sizeof(foo_2)` and attempts to figure out whether the application code groks version 2.

```
if(arg.size == sizeof(foo_2)) {
    // The application groks version 2 of the library. So, arg.z is valid. 
} else {
    // The application uses of version 1 of the library. arg.z is not valid.
}

```

I'm wondering why this won't fail. On GCC 4.6.3, with -O3 flag, both `sizeof(foo)` and `sizeof(foo_2)` are 24. So, won't v2 library code fail to understand if the application is passing a struct of type `foo` or `foo_2`? If yes, how come this approach seems to have been used?

<http://wezfurlong.org/blog/2006/dec/coding-for-coders-api-and-abi-considerations-in-an-evolving-code-base/>

<http://blogs.msdn.com/b/oldnewthing/archive/2003/12/12/56061.aspx>

---

Follow on question: Is there a good reason to favor the use of `sizeof(struct)` for version discrimination? As pointed out in the comments, why not use an explicit `version` member in the shared struct?