[Harbour] HRB problem with inherited classes

[Szakáts Viktor]

With unload an interesting question is what happens
in this scenario:

1. Load HRB1 overloading existing function: HELLO
2. Load HRB2 overloading existing function: HELLO
3. Unload HRB1
4. ? Which version of HELLO will now execute?
5. Unload HRB2
6. ? Which version of HELLO will now execute?

I suppose there should be a stack of versions for all
symbols for this to work.

While patching by itself is nice, we should also be aware
that if we allow such feature, it could very easily create
a huge security hole, where a maliciously extended .hrb
file may redefine some core (app or Harbour) functions
and executing undesired program parts. Same can be done
by mistake also.

One solution for this is to somehow explicitly allow
overloading of existing symbols (VIRTUAL FUNCTION/PROCEDURE),
but by default a function shouldn't change by loading a
.dll IMO.

Brds,
Viktor

On 2009.05.13., at 11:03, J. Lefebvre wrote:

> This mail seem to never reach the list ... New test !
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Hi,
>
> I'm working with HRB files and suddently discovered a serious  
> problem when using Classes defined within the HRB files inheriting  
> from classes from the main program.
>
>
> Suppose we have those two classes, Dialog within the main exe, and  
> MyDlg from the HRB file. (This sample is NOT tested nor compiled, it  
> could contain errors, just here to explain the problem !!!)
>
>
> Main prog ;
>
> Class Dialog
> VAR x
> Method New() Inline x:=1, Self
> Method Destroy()
> Method OnClose() INLINE .F.
> endclass
>
>
> Method Destroy() Class Dialog
> if(::Onclose())
>  x:=NIL
> endif
> Return Self
>
>
>
> HRB prog ;
>
> Class MyDlg inherit Dialog
> VAR y
> Method New() INLINE y:=1, Super:New()
> Method OnClose
> Endclass
>
> Method OnClose() Class MyDlg
> Return .T.
>
>
> When Running the (similar, bug much much biger) prog, at the time of  
> Calling Destroy() method, the super class method is used,  
> so ::Onclose() is called and the class hierarchy is working nicely,  
> to use the onclose() method defined in MyDlg class, within the HRB  
> file.
>
> Then, class system is looking for the associated static function    
> MyDlg_Onclose() defined within the MyDlg Class Header and ... IT  
> DOES'NT FIND IT (as expected) because it should be called by  
> HB_HrbDo(...) and not directly ...
>
>
> Now some questions :
>
> Could we imagine a system where we could create a new HBR function  
> like HB_HBRDYNSYMLOAD(cHbrFile) wich not only would load the HBR  
> header, but also would list all internal function and add them to  
> main symbol list (event more powerfull, it could replace some if  
> some with same name exist, allowing the HRB file to patch program  
> easily)
>
>
> Where should I have a look if I want to add this kind of  
> functionalities ?
>
> I found runner.c but I have to 1) scan HRB to list existing  
> function, 2) scan the actual symbol list and either replace some  
> symbol or add new symbol
>
>
> Finally, I shoud be able to unload the HRB file and restore the  
> symbol list (but I can live without it  :-) ).
>
> Apart the last point, this is how Blinker was working with blinker  
> special DLL for clipper. You can load a Dll with some code (new or  
> existing) and the loader add all the function and vars to the symbol  
> table, eventually replacing existing one. With Blinker, you CAN'T  
> unload it without GPFying your program !!!
>
>
> JF,
>
> _______________________________________________
> Harbour mailing list
> Harbour at harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour