[cap-talk] Coding style in C++, isolating the bad parts with private constructors and friends?

Rob Meijer capibara at xs4all.nl
Mon Dec 14 04:47:31 PST 2009


In a chapter I am writing on practical least privilege in programming, I
try to defend the use of friends and private constructors as a practical
way to isolate the parts of the C++ code that actually communicate with
external libraries and OS API's accessing shared-name-space designated
resources.

I know capability purist will probably say that as C++ isn't even memory
safe, these coding styles don't really matter, but as I am trying to write
my text based on the concept that even with flawed tools there is a lot of
room to improve system integrity, I really do want to try my best at
describing what measures are available while using memory unsafe
languages.

I would really like to hear if given that we know the limitations of
languages like C++ within high integrity computing, if the below construct
when used to isolate accessing shared-name-space designated resources are
indeed a sufficiently high improvement to potential program integrity as
to justify spending a section on explaining it:

class FooCreator;
class Foo {
  public:
    void dostuff(){
       ..
    }
  private:
    ..
    Foo(){
       ..
    }
    friend class FooCreator;
};
int main(int argc,char **argv);
class FooCreator {
  public:
    Foo *createFoo(){
       return new Foo();
    }
  private:
    FooCreator() {
    }
    friend int main(int argc,char **argv);
};




More information about the cap-talk mailing list