Re: Semantic error recovery

bill@amber.csd.harris.com (Bill Leonard)
Wed, 17 Nov 1993 19:19:07 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: Semantic error recovery strohm@mksol.dseg.ti.com (1993-11-12)
Re: Semantic error recovery olsen@verdix.com (1993-11-12)
Re: Semantic error recovery enedervo@adobe.com (1993-11-12)
Re: Semantic error recovery kanze@us-es.sel.de (James Kanze) (1993-11-15)
Re: Semantic error recovery kanze@us-es.sel.de (James Kanze) (1993-11-15)
Re: Semantic error recovery delano@snake.CS.Berkeley.EDU (1993-11-17)
Re: Semantic error recovery bill@amber.csd.harris.com (1993-11-17)
Re: Semantic error recovery weberwu@inf.fu-berlin.de (1993-11-18)
Re: Semantic error recovery bj@hatch.socal.com (1993-11-22)
Re: Semantic error recovery sommerfeld@apollo.hp.com (1993-11-23)
Re: Semantic error recovery geoff@flash.bellcore.com (1993-11-28)
Re: Semantic error recovery bill@amber.csd.harris.com (1993-12-01)
Re: Semantic error recovery geoff@flash.bellcore.com (1993-12-04)
| List of all articles for this month |
Newsgroups: comp.compilers
From: bill@amber.csd.harris.com (Bill Leonard)
Keywords: errors
Organization: Harris CSD, Ft. Lauderdale, FL
References: 93-11-102
Date: Wed, 17 Nov 1993 19:19:07 GMT

the moderator wrote:
>[How many people find it useful for a compiler to chug through and try to
>parse and diagnose an entire file in the presence of errors? I'm just as
>happy with one that finds a few errors and gives up so I can go fix them.
>-John]


delano@snake.CS.Berkeley.EDU writes:
> It's occasionally very useful to have the compiler report all the errors
> it can find. For example, if you are considering porting a large
> application to a system with a compiler that may not be completely
> compatible with the one(s) the application is written in (and most C
> compilers aren't completely compatible, if you have a sufficiently large
> and "sophisticated" application) -- you would like to try to compile the
> whole application, then look at all the error messages to give you an idea
> of what you are up against.


Besides the problem of spurious errors, there is also the problem of
"spurious recovery". For instance, the C++ compiler I am using has a
tendency to tell me "foo undefined" when I type "foo" instead of "fool",
and then ignore the other 200 mispellings! So I end up finding the first
one and fixing it, only to find there were more.


> The same might be true if you are considering a modification to an include
> file or to a macro rather than a port - you would like to see how many
> instances of errors you get, rather than just the number of files that
> contain errors.


And it would be preferable to fix all those errors in one go, rather than
iterating an indeterminate number of times. I sometimes take this
approach when I am considering changing the interface to a member function
-- I simply remove it and recompile, thus getting errors for "undefined
member" that tell me where the function is referenced.


Also, the speed of the compilation is not the only consideration. Most
people working on larger projects tend to use make (or something similar).
If you have hundreds of source files, it can take a long time for each
"compilation", because make has to check to see which of those hundreds of
source files need recompilation. If your source is also being accessed
across a network, it can be even worse. So one tends to want each
compilation to find as many errors as possible.
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com
--


Post a followup to this message

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