Why is it possible to add functions to external library to access internal data

user_1571517 0
Viewed 114

this week i needed a feature in our internal static library but i was too lazy to recompile the library so i just modified the header file and was able to get access to private members. The same was possible to do when the library is a Windows dll.

An example header might look like:

#pragma once

#ifdef DLL
#define DLL_INTERFACE __declspec(dllexport)
#else
#define DLL_INTERFACE
#endif

class DLL_INTERFACE foo
{
public:
    foo(); // init foo::a and foo::b to 0

    int getA() const;
    void setA(int a); // set foo::a to a and foo::b to a+2
private:
    int a;
    int b;
};

Now i added my own functions to the the header that allow me access to its private members like so:

class DLL_INTERFACE foo
{
public:
    foo(); // init foo::a and foo::b to 0

    int getA() const;
    void setA(int a); // set foo::a to a and foo::b to a+2

    int getB() const
    {
        return b;
    }
    void setB(int b)
    {
        this->b = b;
    }
private:
    int a;
    int b;
};

While testing my new functionality and recompiling the library (to not rely on that hack) i realized that this could compromise the internal state of the object.

Why is this allowed/possible to change the header files of a compiled library (dll or static lib)? (I had expected that the compiler or the linker would complain that the object from the library does not match the object defined in the header)

Thanks in advance

static-libraries dll c++
1 Answers

Changing a header in this manner and recompiling a part of the program with the changed header results in a violation of the "One Definition Rule" and thus is undefined behaviour.

This kind of violation could have been detected by a C++ implementation. Such detection is not very challenging technically. Basically, the compiler computes hashes of all definitions that it sees, and stores the names-to-hashes dictionary in the object file, and the linker checks that they all match. The method is not too different from name-mangling that existing implementations employ. However, this entails changes in the linker, and possibly in the object file format, and also increases compilation and link times. Which is why the implementations are not eager to implement it, and consequently the C++ standard is unlikely to mandate it. So it will probably remain a no-diagnostic-required violation.

user_7758060
Related