Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2012-08

Label

12 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Rainer Stratmann

Is it possible to get the adress of a label in a procedure?

label mark1;
procedure s;
begin
 mark1:
end;
var p : pointer;
begin
 p := @mark1;  // does not work;
end;

Reply by email

Rainer Stratmann
to Jonas Maebe
Jonas Maebe wrote
Rainer Stratmann wrote on Thu, 09 Aug 2012: > Is it possible to get the adress of a label in a procedure? Not outside that procedure, no.

Would it be possible to chage it, to get this information?

May be it is only some kind of accident prevention for programmers who do not really know what they are doing. :-)

Show quoted text 5 lines
Jonas _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply by email

Jonas Maebe
to Rainer Stratmann

Rainer Stratmann wrote on Thu, 09 Aug 2012:

Show quoted text 7 lines
Am Thursday 09 August 2012 15:35:54 schrieb Jonas Maebe: > Rainer Stratmann wrote on Thu, 09 Aug 2012: > > Is it possible to get the adress of a label in a procedure? > > Not outside that procedure, no. Would it be possible to chage it, to get this information?

No. It would require quite a bit of rewriting in the compiler for little or no gain, and cause problems with smart linking on some platforms. Delphi presumably doesn't support it for the same reason.

Jonas

Reply by email

Jonas Maebe
to Sven Barth

Sven Barth wrote on Thu, 09 Aug 2012:

Show quoted text 9 lines
Am 09.08.2012 15:35, schrieb Jonas Maebe: > > Rainer Stratmann wrote on Thu, 09 Aug 2012: > >> Is it possible to get the adress of a label in a procedure? > > Not outside that procedure, no. Just because it sounds that way: is it possible inside the procedure?

Yes, if the label declaration is also inside the procedure. You can only take the address of a globally declared label iff a) the label is also defined in the global scope ("begin .. end.", initialization, finalization)
b) the label's address is also taken in one of those blocks. It doesn't have to be the same one though, because the compiler keeps the code for all of those blocks in memory at the same time and hence a label defined in one of those is still valid while generating the code for another one. That's more a compiler implementation aspect than a conscious design decision though

Jonas

Reply by email

Rainer Stratmann
to Jonas Maebe
Jonas Maebe wrote 19 lines
Sven Barth wrote on Thu, 09 Aug 2012: > Am 09.08.2012 15:35, schrieb Jonas Maebe: >> Rainer Stratmann wrote on Thu, 09 Aug 2012: >>> Is it possible to get the adress of a label in a procedure? >> >> Not outside that procedure, no. > > Just because it sounds that way: is it possible inside the procedure? Yes, if the label declaration is also inside the procedure. You can only take the address of a globally declared label iff a) the label is also defined in the global scope ("begin .. end.", initialization, finalization) b) the label's address is also taken in one of those blocks. It doesn't have to be the same one though, because the compiler keeps the code for all of those blocks in memory at the same time and hence a label defined in one of those is still valid while generating the code for another one. That's more a compiler implementation aspect than a conscious design decision though

If you have a label in a procedure and declare this procedure as inline procedure then it gives also problems (Fatal: compilation aborted!).

Reply by email

Thomas Schatzl
to Rainer Stratmann

Hi,

Rainer Stratmann wrote 14 lines
Just because it sounds that way: is it possible inside the procedure? > Yes, if the label declaration is also inside the procedure. You can > only take the address of a globally declared label iff > a) the label is also defined in the global scope ("begin .. end.", > initialization, finalization) > b) the label's address is also taken in one of those blocks. It > doesn't have to be the same one though, because the compiler keeps the > code for all of those blocks in memory at the same time and hence a > label defined in one of those is still valid while generating the code > for another one. That's more a compiler implementation aspect than a > conscious design decision though If you have a label in a procedure and declare this procedure as inline procedure then it gives also problems (Fatal: compilation aborted!).

just fyi, generally the "inline" keyword is only a suggestion to the compiler. There is no guarantee whatsoever that it will actually inline that particular method. There are, as you found out, several limitations for that. Actually, there are more, like size of the inlined method, possible use of exception handling, etc. (I'm not sure about the exact conditions btw, maybe there's some documentation in the manuals)

Do not use it if you code something that relies on actual inlining - it seems to me that you require that in whatever you're trying to achieve.

Only macros are guaranteed to be inlined - because they are simple text replacement instructions to the compiler.

Hth,
Thomas

Reply by email

Jonas Maebe
to Rainer Stratmann: If you have a label in a procedure and declare this procedure as inline procedure then it…

Rainer Stratmann wrote on Thu, 09 Aug 2012:

If you have a label in a procedure and declare this procedure as inline procedure then it gives also problems (Fatal: compilation aborted!).

That is the generic error message that is shown at the end of every failed compilation. I guess you mean this error message:

Error: Taking the address of labels defined outside the current scope isn't allowed

Taking the address of a label inside an inlined routine is indeed not supported.

I would really recommend you (again) to use resourcestrings.

Jonas

Reply by email

Rainer Stratmann
to Jonas Maebe
Jonas Maebe wrote
I would really recommend you (again) to use resourcestrings.

You say that is not possible and that is not possible (or someone can say: you don't want to go deep in it).

Beyond that you recommend me your style of programming.

I see everywhere limitations.

Reply by email

Jonas Maebe
to Rainer Stratmann

Rainer Stratmann wrote on Thu, 09 Aug 2012:

Show quoted text 5 lines
Am Thursday 09 August 2012 17:18:09 schrieb Jonas Maebe: > I would really recommend you (again) to use resourcestrings. You say that is not possible and that is not possible (or someone can say: you don't want to go deep in it).

You noticed yourself what is and what is not possible. And I am indeed not interested in adding macro assembler features to FPC.

Beyond that you recommend me your style of programming.

I recommend existing functionality for exactly the kind of feature you want to implement, because it already exits, is documented, has been tested and is being used by many people.

It's not "my style of programming". I've never used resourcestrings in my life (because I've never worked on a multilingual program, not because I've used something else instead).

Jonas

Reply by email

Sven Barth
to Jonas Maebe
Jonas Maebe wrote
It's not "my style of programming". I've never used resourcestrings in my life (because I've never worked on a multilingual program, not because I've used something else instead).

The compiler is a multilingual program and uses a different mechanism than resourcestrings ;)

Though, @Rainer, that still won't help you.

Regards,
Sven

Reply by email