[fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing

[Rainer Stratmann]

Am Wednesday 15 August 2012 19:58:02 schrieb Marco van de Voort:
> No. The route was this:
>
> - In an earlier msg I mentioned this as dxgettext limitation (since I ran
>  into it)
> - In a later msg you said you got weary of dxgettext because of "problems"
>    with it.
> - I replied that it was not a problem, but a limitation of the concept, and
>    that your system had it too.

Howsoever, I am not familiar with dxgettext.
By now I can not see a problem to use my concept.

For me it all mainly comes to the questions of providing the pointer to the 
text snippets and the caller adresses.
If the compiler provides this information then programming would be easier.
The other things (double texts, coding of text, ...) are subordinated and 
could be solved when it is needed.

> I never asked you to have a solution for it. I don't see the particular
> advantage of your system over gettext anyway.

For me the advantage is that I have already busy with that stuff some time and 
I had partly a solution except the pointers to the strings and the caller 
adresses which I asked to be provided.

> > > > <-> utf8.
> > >
> > > What do you assume about the codepage of literals? Do you pass the
> > > right -Fc parameters for that?
> >
> > Please explain it more.
>
> If there is a _('whatever')    (or whatever your notation is)
>
> what do you assume about 'whatever' 's codepage?

ascii
In the main program I only need ascii code (german, english, some other 
european laguages which are compatible with ascii).
'Exotic' languages can only be accessed by the browser interface (utf8 which 
means also ascii).

> > > > Another step more that means more work and less easiness (less
> > > > userfriendly).
> > >
> > > Explain. You need to scan some way too.
> >
> > Yes at programstart with searching the opcode for calls and loading the
> > pchar const in EAX.
>
> _always_ ? Scary.

By now yes. The searching routine gets all text information now.
If for example push (to the stack) is also used later than I can adapt easily.

> Anyway, my point was that you scan either which way. Source or binary.
Binary is much more easier for me and takes less effort.
>
> The source has a build requirement, is architecture dependent and generally
> more portable. Binary might be easier to only get the linkedin texts.
The solution would be that the compiler stores the information in a table and 
then is available like already described.
>
> Actually proof of concept might be worthwhile for that purpose in
> combination with gettext. OTOH, gettext alos translates stuff from
> resources (like forms)