Intended Security Hole?

[Maxim Fomin]

On Wednesday, 24 October 2012 at 21:07:28 UTC, Manfred Nowak 
wrote:
> Chris Cain wrote:
>
>> So, no, the implementation wouldn't be changed during runtime 
>> since it must be provided when linking.
>
> Thats an expressed intent only. Reason: the linker does not 
> know any
> thing about the language; the linker would be satisfied if there
> exists any function the linker can link to ... but the linker 
> would
> not prohibit any replacement of that function during runtime.
>
> Conclusion: until a proof of the imposibility, there might exist
> cases in which such replacement is possible.
>
> Example for a _visible_ hijack:
> -----------------------------------------------------
> private import std.stdio;
>
> abstract class Base {
>     void   foo(float f);
> }
>
> class Derived1 : Base {
>     void   foo(float f) { writefln("f =1= %f", f); }
> }
> class Derived2 : Base {
>     void   foo(float f) { writefln("f =2= %f", f); }
> }
>
> void main() {
>     Base b;
>     float f = 2.5;
>
>     auto d1 = new Derived1;
>     b= d1;
>     b.foo( f); // f =1= 2.500000
>
>     auto d2= new Derived2;
>     b= d2;
>     b.foo( f); // f =2= 2.500000
> }
> -----------------------------------------

What is wrong here?

> Can be proved that it is impossible to make the assignment `b= 
> d2;'
> invisible?

Assignment can be "invisible", for ex. if one of functions in 
_visible_ hijack.d is called from other module with derived class 
instance when base class instance is expected. But is not 
hijacking, it is inheriting.

> -manfred