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;
Mailing lists / fpc-pascal / 2012-08
12 messages · 4 people ·
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
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;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.
Jonas
Jonas Maebe wroteRainer 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. :-)
Rainer Stratmann wrote on Thu, 09 Aug 2012:
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
Rainer Stratmann wrote on Thu, 09 Aug 2012: Not outside that procedure, no. Jonas
Just because it sounds that way: is it possible inside the procedure?
Regards,
Sven
Sven Barth wrote on Thu, 09 Aug 2012:
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
If you have a label in a procedure and declare this procedure as inline procedure then it gives also problems (Fatal: compilation aborted!).
Hi,
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
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
Jonas Maebe wroteI 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.
Rainer Stratmann wrote on Thu, 09 Aug 2012:
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
Jonas Maebe wroteIt'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