|Parsing circular includes... email@example.com (Orlando Llanes) (2002-09-14)|
|Re: Parsing circular includes... firstname.lastname@example.org (Peter Flass) (2002-09-14)|
|Re: Parsing circular includes... email@example.com (Bob Sheff) (2002-09-14)|
|From:||"Peter Flass" <firstname.lastname@example.org>|
|Date:||14 Sep 2002 16:18:37 -0400|
|Posted-Date:||14 Sep 2002 16:18:37 EDT|
It would seem processing enough circular includes would usually
exhaust some resource: memory, disk space, etc. Two alternatives
would be to limit the number of *levels* of include to, say, three or
five, which would indirectly solve the problem, or mainyain a table of
includes, which would have finite size and have the same effect. I
say, let the programmer beware.
Orlando Llanes wrote:
> I'm currently working on an assembler, part of what I need is the
> ability to process include files. I understand that I simply save the
> current file pointer, read in the include file, and restore the previous
> file pointer.
> What I'm having trouble with are circular includes. In other words, when
> file A includes file B, and file B includes file A.
> Am I being a wimp by not allowing circular references?
Return to the
Search the comp.compilers archives again.