Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Parsing circular includes... ojl@hotmail.com (Orlando Llanes) (2002-09-14) |
| Re: Parsing circular includes... peter_flass@yahoo.com (Peter Flass) (2002-09-14) |
| Re: Parsing circular includes... bsheff2@jyahoo.com (Bob Sheff) (2002-09-14) |
| From: | "Peter Flass" <peter_flass@yahoo.com> |
| Newsgroups: | comp.compilers |
| Date: | 14 Sep 2002 16:18:37 -0400 |
| Organization: | Road Runner |
| References: | 02-09-090 |
| Keywords: | practice |
| 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
comp.compilers page.
Search the
comp.compilers archives again.