Thread: Class access enforcement

Your friend at Apple doesn't know what he or she is talking about.

If you want an example;

Code:

class X
{
    public:
        int x;
    protected:
        int y;
    private:
        int z;
};

int main()
{
     X variable;
     variable.x = 5;   // OK:  modifying public member
    
     variable.y = 10;  // trigger a compiler error due to attempt to access protected member of X

     variable.z = 15;  // trigger a compiler error due to attempt to access private member of X


      //  now do the same with a pointer

     X *p = &variable;   //   make p point at a valid object

     p->x = 5;   // OK:  modifying public member
    
     p->y = 10;  // trigger a compiler error due to attempt to access protected member of X

     p->z = 15;  // trigger a compiler error due to attempt to access private member of X
}

There are various techniques to deliberately circumvent the above, but they all involve some form of undefined behaviour (i.e. there is no guarantee they will give the same result for different compilers). If you deliberately use those techniques (and it is unlikely you will use them accidentally) you accept the consequences.

In C++, if a programmer is determined to misuse specific data, the language always provides the power to do that.

However, You can hide the structure of a class form the programmer so that he doesn't know what he's modifying, and you can hide the implementation of functions in linkable libraries.

Private/protected mode is not a security feature, but a tool for the developer to orgonise code. This is as true in Java as it is in C++. So preventing the developer from doing what he is determined to do is not useful to the developer. As long private data and functions are used traditionally, requiring all contrairy to intent statements to be explicitly stated through casting is sufficient. It ensures that privateness is enforced precicely when the developer want it to be enforced.

I suppose that as private data can be used as a security feature in java though serialized classes, but a determined developer can circumvent that by modifying his JVM, or writing his own de-serializer. So other security methods are preferred.

re:grumpy

I agree with grumpy your friend at Apple probably doesn't know what he's talking about. He is however technically right in his assertion. However, he is wrong in thinking that this is a drawback of C++.

Here is an example of a well defined breaking of privatisation:

Code:

class T
{
  int x;
  public: 
  const int &getX(){
    return x;
  }
}

void func(){
    const_cast<int&>( T().getX() ) = 1;
}

Here you are violating the privacy contract of class T, but the result is guaranteed to work, because of the nature of cost_cast.

By the way, DON'T DO THIS.

Originally Posted by King Mir

Here is an example of a well defined breaking of privatisation:

Code:

class T
{
  int x;

  const int &getX(){
    return x;
  }
}

void func(){
    const_cast<int>( T().getX() ) = 1;
}

Here you are violating the privacy contract of class T, but the result is guaranteed to work, because of the nature of cost_cast.

Not true.

If we address the fact that your example won't compile (you need to make getX() public, and the const_cast needs to be to an int&).....

The const_cast is accepted by the compiler, but the result of using the non-const reference to modify the underlying variable yields undefined behaviour. In practice, it may work as you expect, but there is no absolute guarantee it will.

The following GotW link will tell you absolutely everything you need to know about this:
http://www.gotw.ca/gotw/076.htm

"C++ tries to protect against Murphy, not Machiavelli."

You can subvert just about everything C++ does simply by using raw pointers. At the same time, the sheer ugliness of such code should alert you that you're doing something wrong. If you still persist in doing it, that's your fault alone, and not that of C++. The enforced access system is there to prevent mistakes, not abuse.

On the flip side, unless you're in a restricted security sandbox, you can easily subvert Java's access rules. Object-relational mappers and unit test frameworks do it on a regular basis.

Originally Posted by grumpy

The const_cast is accepted by the compiler, but the result of using the non-const reference to modify the underlying variable yields undefined behaviour. In practice, it may work as you expect, but there is no absolute guarantee it will.

The standard guarantees that if the value was not originally const, that the modification is well defined.

Originally Posted by King Mir

The standard guarantees that if the value was not originally const, that the modification is well defined.

Yeah; the difficulty lies in determining if the value was originally const. In your example you gave above, T() is a temporary, and temporaries are inherently const during their lifetime (from the point of return from their constructor until the point of entry to their destructor). Try passing a temporary object to a function that accepts a non-const reference.

Yes, there are cases where const_cast<> can be used to discard constness, and the resultant pointer/reference can be used to modify the underlying object in a well-defined manner. In my experience (which I concede is not an absolute measure of common practice) the majority of cases where programmers use const_cast to discard constness do not fall into those narrow cases. The most common case I've seen is to hack a class that does not supply an appropriate setter function. const_cast is then used to subvert a getter that returns a const reference. The problem with that, practically, is when other member functions of the class assume that the affected data is fixed and the functioning of the class can be compromised - particularly if some member functions maintain a copy of the data, derive the same value in another way, or rely on the value being in some specified range that gets subverted. And the programmers involved defended the practice using the argument that "const_cast is well-defined".

Originally Posted by grumpy

Yeah; the difficulty lies in determining if the value was originally const. In your example you gave above, T() is a temporary, and temporaries are inherently const during their lifetime (from the point of return from their constructor until the point of entry to their destructor). Try passing a temporary object to a function that accepts a non-const reference.

No, they aren't. You can't bind temporaries to non-const references, but that's because the changes wouldn't be visible, so the rule is there to catch mistakes. But temporaries aren't inherently const. For example, you can call a non-const member function of the temporary, and it can easily modify the object:

Code:

struct S {
  int i;
  void f() { i = 100; }
}

int main()
{
  S().f();
}

Meh, temporaries are r-values and the compiler simply won't allow you to bind them to non-const variables without tricks (but they are not const).

Originally Posted by grumpy

Yeah; the difficulty lies in determining if the value was originally const. In your example you gave above, T() is a temporary, and temporaries are inherently const during their lifetime (from the point of return from their constructor until the point of entry to their destructor). Try passing a temporary object to a function that accepts a non-const reference.

Yes, there are cases where const_cast<> can be used to discard constness, and the resultant pointer/reference can be used to modify the underlying object in a well-defined manner. In my experience (which I concede is not an absolute measure of common practice) the majority of cases where programmers use const_cast to discard constness do not fall into those narrow cases. The most common case I've seen is to hack a class that does not supply an appropriate setter function. const_cast is then used to subvert a getter that returns a const reference. The problem with that, practically, is when other member functions of the class assume that the affected data is fixed and the functioning of the class can be compromised - particularly if some member functions maintain a copy of the data, derive the same value in another way, or rely on the value being in some specified range that gets subverted. And the programmers involved defended the practice using the argument that "const_cast is well-defined".

I totally agree that the example I posted is bad code. I said as much when I posted it. It is however, well defined. This means that it is a very bad hack, not simply incorrect.