Am Wednesday 15 August 2012 16:45:03 schrieb Lukasz Sokol: > >> 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' :)
For me it was quite easy to see a system in how the compiler generates the opcodes. There aren't this much variants to do so. > > I can not see any insolvable problem here. > > Yeah. But it is labour intensive. Initial search code about 3 hours work. Add another search method (which should be very rarely) about 10-30 minutes work I guess. > >> 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?] Please explain. I do not change the code. I am only searching some pointers. > 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. If the pointers were provided natively then scaning the source (labour intensive) is no more necessary. > > 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 Very huge labour intensive I think! _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal