[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