Re: Question about GOTO syntax checking

Chris F Clark <cfc@world.std.com>
19 Jul 1999 01:21:18 -0400

          From comp.compilers

Related articles
Question about GOTO syntax checking magnus.jansson@mbox319.swipnet.se (Magnus Jansson) (1999-07-14)
Re: Question about GOTO syntax checking rkrayhawk@aol.com (1999-07-14)
Re: Question about GOTO syntax checking thiadmer@compuphase.com (1999-07-19)
Re: Question about GOTO syntax checking cfc@world.std.com (Chris F Clark) (1999-07-19)
Re: Question about GOTO syntax checking jonathan_barker@my-deja.com (1999-07-20)
| List of all articles for this month |
From: Chris F Clark <cfc@world.std.com>
Newsgroups: comp.compilers
Date: 19 Jul 1999 01:21:18 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 99-07-053
Keywords: analysis

> Hi I'm a real beginner in this, excuse me if my question is
> stupid. But: How do I check that a goto statement doesn't end up inside
> an if statement or a loop?
>
> begin
> ....
> goto l1;
>
> if a>0 then begin
> ....
> L1:
> ....
> end;


One simple way to check is to use the model of "nested scopes". That
is, you keep your labels in a symbol table that supports the concept
of scopes. You push a scope when you enter a block that you are not
allowed to jump into from the outside and you pop the scope when you
leave that context. when you are searching for a label you allow
yourself to look at the current label scope and all label scopes
containing it.


In your example, the goto l1 will be in an outer scope, and will not
see the label L1 in the inner scope, but could see an l1 label that
was further outward (in a statement that enclosed all the above).


Since it looks like you are implementing a Pascal dialect, you will
need a symbol table that handles nested scopes to handle variable
declarations in nested blocks. You can use similar (or perhaps the
same) code to implement your label symbol table.


One question you will have to determine is whether you should use one
symbol table for both or have separate symbol tables for the two
disjoint uses. That will depend on whether a label name can overlap
with a variable (or type) name, whether the boundaries where names
come into and leave existence match, and what is easiest to implement.


For example, while I was a consultant at Honeywell years ago we did an
ANSI C compiler that used one scope object for both labels and
variables. However, because C splits the two concepts into separate
namespaces, the scope object had two linked lists in it. (If I recall
correctly, in the end, it had three because structure tags went into a
third namespace (or perhaps the label and variable namespaces were
shared and only the tag namespace was separate). In any case, we
designed it that way because most of the time the scope boundaries
were the same, so the pushes and pops of scope objects matched. The
linked lists allowed us to access all objects of either namespace
easily.


By the way, in many Pascal dialects there are further complications
that labels have to be declared before use. This tends to cause
implementors to use a symbol table that enters the label names upon
seeing their declaration and use that to connect the goto statements
to their targets. However, that symbol table won't distinguish the
inner scopes you need to prevent jumping into nested statements. The
end result is that you may need two symbol tables to distinguish both
restrictions on labels (if your dialect has the declaration before use
restriction as well as the no jump into nested construct restriction).


You might also finese the jump into nested statements issue by keeping
fields within the label symbol table entry that track the outermost
scope in which a goto to the label appears and the scope in which the
label (target) actually appears. If you use that approach, any goto
statement takes a union of its current scope with the "goto scope" in
the label entry (that will always move you toward farther outward
scopes). At the end, you can compare the goto scope and thelabel
target scope and if the label target scope does not contain (or match)
the goto scope, then at least one goto jumped into a nested statement.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
------------------------------------------------------------------------------
Web Site in Progress: Web Site : http://world.std.com/~compres


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.