On 15/08/2012 15:17, Rainer Stratmann wrote:

> 
> Then the
> mov  pcharconst , EAX
> command also had changed.
> At every start of the program I see if it works here.
> If it works here ist works outside also.
> 
>> For example if you add/remove units and rebuild.
> 
> All pchar adresses are searched at programstart.
> 
>> For example if FPC internals decide to add or remove some padding in front
>> of the constants.
> 
> Very unlikely.
> For which reason should there be padding in front?

For the reason that they always say not to rely on 'internal workings of the 
FPC' :)

> I can not see any insolvable problem here.
> 
Yeah. But it is labour intensive.

>> Will all your translation work go to waste ?
> 
> Then I would have a look at the opcodes directly and see what has been 
> changed 
> and likely find a solution.
> 
See above.

> If the maintainers decide to build in the suggested function above then 
> everthing is solved. By now no one of the maintainers wants this.
> 

I can understand why, more or less - this could be a security flaw if you can 
find
the final procedure call address like that [and then inject/patch it from 
outside,
while the program is running - see what I mean?]
Sort of the reason why Linux doesn't export System.map any more...

And the sort of reason why (dx)gettext scans the _source_ not the binary.

> I also can ask what happens if there are no more maintainers for fpc?
Then you can fork it and maintain for you and for others for eternal glory :J

Lukasz

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to