What causes this?
error: label `nonlocal_exit_18' not set
It's happening right after the declaration of a procedure in a unit.
Jerry
Waldek Hebisch wrote:
What causes this?
error: label `nonlocal_exit_18' not set
It's happening right after the declaration of a procedure in a unit.
It is a bug: what version you use and what input reproduce this message?
I vaguely remember that this error message appears when Exit( procname) is used and there is another error in the source code. But an example that reproduces it would be better.
Regards,
Adriaan van Os
Waldek Hebisch wrote:
What causes this?
error: label `nonlocal_exit_18' not set
It's happening right after the declaration of a procedure in a unit.
It is a bug: what version you use and what input reproduce this message?
I vaguely remember that this error message appears when Exit ( procname) is used and there is another error in the source code. But an example that reproduces it would be better.
Regards,
Adriaan van Os
[Original poster] I sent the rather lengthy source listing that caused the problem to Waldek off-list along with version info and error output. He wasn't able to reproduce the problem, but pointed out that there was another error in my code. So here is a short etymology (entomology?) of the problem:
Source was created as FORTRAN many years ago and then converted to THINK Pascal.
It then compiled OK under Codewarrior 8.3 Pascal a few years ago (maybe with some changes).
I tried to port it to GPC a couple days ago. GPC didn't like my use of label and goto (FORTRAN cruft, used to to exit the program), even thought CW was cool with it. I felt that GPC was wrong in complaining, but usually it's me that's wrong. At the same time, it complained about nonlocal_exit_18.
I replaced the label and goto with an Exit statement--no arguments with Exit. At about the same time I brilliantly replaced StringOf with WriteStr (that's right--I tried to use WriteStr as a function, not a procedure). The original error about the label and goto went away, but I got two errors related to my botched use of WriteStr, followed by the remaining nonlocal_exit_18 error.
I fixed the WriteStr problem, at which time the nonlocal_exit_18 error also disappeared.
Let me know if you want the source.
Jerry
Jerry wrote:
I tried to port it to GPC a couple days ago. GPC didn't like my use of label and goto (FORTRAN cruft, used to to exit the program), even thought CW was cool with it. I felt that GPC was wrong in complaining, but usually it's me that's wrong. At the same time, it complained about nonlocal_exit_18.
I replaced the label and goto with an Exit statement--no arguments with Exit. At about the same time I brilliantly replaced StringOf with WriteStr (that's right--I tried to use WriteStr as a function, not a procedure). The original error about the label and goto went away, but I got two errors related to my botched use of WriteStr, followed by the remaining nonlocal_exit_18 error.
Your usage of goto looks fine: there are restrictions on goto usage, but using then to jump to the end of routine is legal. I suspect that you had another error (gpc-20050331 surely complained about StringOf).
Waldek Hebisch wrote:
What causes this?
error: label `nonlocal_exit_18' not set
It's happening right after the declaration of a procedure in a unit.
It is a bug: what version you use and what input reproduce this message?
I vaguely remember that this error message appears when Exit( procname) is used and there is another error in the source code. But an example that reproduces it would be better.
{$mac-pascal} program testexit;
procedure P; begin Exit(P);
begin P end.
Regards,
Adriaan van Os
Waldek Hebisch wrote:
What causes this?
error: label `nonlocal_exit_18' not set
It's happening right after the declaration of a procedure in a unit.
It is a bug: what version you use and what input reproduce this message?
I vaguely remember that this error message appears when Exit( procname) is used and there is another error in the source code. But an example that reproduces it would be better.
{$mac-pascal} program testexit;
procedure P; begin Exit(P);
begin P end.
But to answer Waldek's question, with gpc-20060215 the error doesn't seem to appear. Is this in the bug-fix list ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
What causes this?
error: label `nonlocal_exit_18' not set
It's happening right after the declaration of a procedure in a unit.
It is a bug: what version you use and what input reproduce this message?
I vaguely remember that this error message appears when Exit( procname) is used and there is another error in the source code. But an example that reproduces it would be better.
{$mac-pascal} program testexit;
procedure P; begin Exit(P);
begin P end.
But to answer Waldek's question, with gpc-20060215 the error doesn't seem to appear. Is this in the bug-fix list ?
I don't see it there. But it must say that, at least to me, such problems are not the highest priority. Generally, it's impossible to do the "best" thing after a recognized error, as it's generally even impossible to know what's "best" without mind-reading. Sometimes, seemingly unrelated changed affect such behaviour, and I usually don't really make effort to prevent this, as long as it doesn't prevent the detection of the original error, of course.
So, in general, while it's often useful to see several error messages at once, only the first one should be considered reliable. If subsequent messages seem strange or wrong, it's always recommended to fix the preceding ones and compile again.
That said, if it's easy to prevent spurious follow-up errors, I like to do so, and sometimes when I do, I don't actually document this in the todo list ...
Frank
Adriaan van Os wrote:
I vaguely remember that this error message appears when Exit( procname) is used and there is another error in the source code. But an example that reproduces it would be better.
{$mac-pascal} program testexit;
procedure P; begin Exit(P);
begin P end.
But to answer Waldek's question, with gpc-20060215 the error doesn't seem to appear. Is this in the bug-fix list ?
With your program and gpc-20050331 I got the message (in fact "proper" compiler options are crucial here). The same can not happen in gpc-20060215 due to fix for `ice4.pas'.