Hiding a structure in C, is this undefined behaviour?

Question

I'm creating a library and I want to both hide and protect (make unwritable) a structure type (can only edit using library functions). I'm using:

typedef _STRINGLIB_STRING_CONST_ struct
{
    #if defined(_STRINGLIB_OVERLOADING_WAIT_) || defined(_STRINGLIB_STRING_ACCESSIBLE_)
    //actual string
    char *getString;
    //string size in bytes
    size_t getSize;
    //string size in characters (=size in bytes-1)
    size_t getSizeChars;
    //should both point to _STRINGLIB_ALLOCATION_TRUE_ when string is allocated
    void *stringAllocation;
    void *stringSignature;
    #else
    struct
    {
        size_t _block_a;
        void *_block_b;
        void *_block_c;
        void *_block_d;
        size_t _block_e;
    }_block;
    #endif // _STRINGLIB_OVERLOADING_WAIT_
}String;

where _STRINGLIB_STRING_CONST_ is always const unless the header is called from source file or the user declared _STRINGLIB_STRING_ACCESSIBLE_ before including the library; _STRINGLIB_OVERLOADING_WAIT_ is declared by the source file (and undeclared right after).

It looks like it works fine (i'm using GCC 4.9.2) but I want to be sure whether this is always OK or undefined behaviour.

.

.

ADDITIONAL INFORMATION: forgot to mention i have these definitions on top of the stringlib.h file:

#ifdef _STRINGLIB_OVERLOADING_WAIT_
#undef _STRINGLIB_STRING_CONST_
#define _STRINGLIB_STRING_CONST_
#elif !defined(_STRINGLIB_STRING_ACCESSIBLE_)
#undef _STRINGLIB_STRING_CONST_
#define _STRINGLIB_STRING_CONST_ const
#else
#undef _STRINGLIB_STRING_CONST_
#define _STRINGLIB_STRING_CONST_
#endif // _STRINGLIB_OVERLOADING_WAIT_

#ifndef _STRINGLIB_H_
#define _STRINGLIB_H_
//<...>

Answer 1

It is not undefined behaviour: it is perfectly well defined what happens. However it is still not a very good idea because the definition of the struct depends on what plaform you used and how you compiled it. This implicit dependency is carried through in all places that use or reference the struct type. This is more or less the ABI of the struct.

This means that if during compilation #1 defined(_STRINGLIB_OVERLOADING_WAIT_) is false, but during subsequent compilation #2 it is true the resulting code of both compilations may not be able to work with each other correctly. The ABIs of #1 and #2 differ, so they are not compatible: mixing them is what leads to undefined behaviour.

So the answer is: this is not undefined behaviour, until you do other things (which you may not even be aware of doing) that mix ABIs. At that point you probably have undefined behaviour lurking in your code.

Your compiler and linker will not necessarily detect this (especially not with pointers to structs) which may lead to mysterious and hard to track down crashes when code written for ABI #1 does things that don't work for ABI #2 or vice versa. (Invalid read/writes being the most obvious, but also things like sizeof() may not work correctly.)

Answer 2

As others have mentioned, having a set of #define's that change the definition of the struct can lead to undefined behavior. Just because the user shouldn't change a particular set of defines doesn't mean they can't. You won't want to give them that flexibility.

The best way to handle this, as mentioned in the comments is with an opaque type.

In your header file you would declare the struct but not define it:

typedef struct String String;

The user would be unable to even create an variable of this type. However, they can create a pointer to this type which they can't dereference (since there's no definition).

Your library source would contain the actual definition of the struct:

struct String {
    char *getString;
    size_t getSize;
    size_t getSizeChars;
    void *stringAllocation;
    void *stringSignature;
};

The functions in the library would accept a String * which could then operate on it. Included in this library would be a creation function which returns a String * to the user and a destroy function which accepts a String * that would deallocate it.

Answer 3

As far as I can see, it is undefined behaviour.

The client code, presumably, declares Strings:

 String s;

These are declared to be const. You then (again, presumably) pass the address of that object to a library function;

string_set(&s, "abc");

And the library function's implementation treats the received pointer as though it were mutable.

Mutating an object which was originally declared const is UB. Although with GCC, you may only experience the problem with file-scoped Strings, it is still UB even for Strings with automatic allocation. (The constness of the struct might be taken into account for optimisation.)

Also, your two alternatives disagree in the order of the types, so they are not compatible. And char* is not compatible with void*. So those are also problematic, although with GCC you won't see any problem. (It would be a problem if a pointer were eight bytes with an eight-byte alignment, and size_t were only four bytes with a four-byte alignment. That would make the size of the "fake" object 40 bytes, including two four-byte paddings, while the "real" object, which has the size_ts together, would fit into 32 paddingless bytes. Even without that justification, they are incompatible structs and that's UB.)