Proposition for change in D regarding Inheriting overloaded methods
Manfred Nowak
svv1999 at hotmail.com
Tue Aug 7 12:17:59 PDT 2007
Walter Bright wrote
> closes all the known hijacking issues.
If accessing data declared private in another not imported module can
be called hijacking there is at least one more issue:
Defining a Base class:
module def;
class Base{int i;}
and defining a Derived class with some operations and some private data
`hidden':
module def2;
import std.stdio;
import def;
class Derived:Base{
private:
int hidden=41; // foreign access possible
public:
void process( inout Base p){
scope d= new Derived;
d.hidden= 666;
d.i+=1;
p= d; // no upcast needed
}
void read( Base p){
scope d= cast(Derived)p; //downcast needed
assert( d !is null);
writefln( "def2:", d.hidden);
}
}
and having a module that does some work:
module mod;
private import std.stdio, def, def2;
public:
void process( inout Base p){
scope d= new Derived;
d.process= p; // stores Base, drops Derived
// do something with d?
}
void read( Base p){
scope d= new Derived;
d.read= p; // drops Derived
// do something with d?
}
the following claim is currently (dmd.1.016,win32) true::
! One can access the `private' data `hidden' defined in `module def2'
! by having access only to sources of `module def' and `module mod'.
This are about 25 LOC and if D is indeed designed to support auditing
well, it should be easy to spot that leak.
-manfred
More information about the Digitalmars-d
mailing list