Adding members to a C-style struct and backwards compatibility

Question

Say I have a struct defined somewhere deep in low-level code used all over the place in the most crazy and unknown ways:

struct T {
    unsigned short name_len;
    char d_name[LENGTH];
}

With accompanying functions that fill d_name with whatever needs to be put there, like

struct T* fill( somethingOrOther* X)

And I would like to extend the old struct+function to include a new variable:

struct T {
    unsigned short name_len;
    char d_name[LENGTH];
    unsigned short type_len;
    char d_type;
}

and the new version of the function would also fill the d_type variable with useful things.

Would this type of change break the API? Couldn't I just use the new T instead of the old T, and additionally access the new members?

Thanks.

Answer 1

Yes- when you use an opaque pointer like that, then it is irrelevant of the contents. As long as your users only ever used the opaque pointers, you can muck around with the struct and it's implementation all you like.

Answer 2

If T really is used all over the place in crazy and unknown ways, then a change like that is likely to break something. Somewhere there will be a piece of code that has a local declaration of T instead of using your header file, or casts a 'mystruct *' to a 'T *', or something equally repugnant.

Answer 3

It might make sense to extend your structs like this:

struct newT {
    struct T t;
    int newElement;
    ...
}

Then you can safely use a newT pointer as a T pointer; the C standard guarantees that there is no padding before the first element of a struct.

Answer 4

As long as the code using this API only obtains T objects as pointers returned by the library, and does not declare them itself, malloc them itself (using sizeof(struct T)), or do anything else that depends on the size of the struct, then it should be fine. If the calling code accessed the contents of the struct, you need to make sure you put new members at the end of the struct.

One possible additional consideration is whether any code depends on d_name being at the end of the structure in order to allocate space for and store larger names if the declared size does not fit. I only bring this up because the names of the members suggest the struct is something like dirent and that's traditional practice for dirent.

Answer 5

Crazy and unknown is not good. The best bet is to scan through the codebase for struct T and examine how it is used, with the alternative approach of changing it and see if something breaks... If the code only uses opaque pointers, you should be on the safe side. If the code accesses the members, but doesn't do something weird, you should be safe too, with a complete recompilation.

If it does something weird, like the examples of rettops, even Jukka's tip may not help. The code could use a hardcoded value for the sizeof to do pointer arithmetic within an array of these structs...