Why C/C++ errors are SO obscure/devious??

[Massimo Soricetti]

Hello,

I'm not a C newbie, but I'm teaching C programming (well... FIRST
programming and then C) to other guys these days and it's driving me to
some reflexions on the language.

It's not uncommon to forget a } writing code, and at compiling time get
an error 18956778 lines after the mistake, in an otherwise absolutely
correct piece of code. Or, sometimes in my journeys I got errors
reported in a file, checked and found it correct, and discovered it was
caused by an error in another file. And in general, I noted that many,
if not all, error messages from the compiler are VERY short and cryptic,
while a couple of words more could sometimes help a lot in understanding
what's wrong and where, for newbies. Well, not only for them... maybe a
compiler switch --NOOB_ERR_MSGS could be very handy for some people )

Why can't a compiler give more accurate informations about errors?
Shouldn't this save time, stress and money?

Another example: have you ever met the error line "Multiple definitions
of..."?

For example, why can't a compiler start a negotiation "on the fly" like
this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>
Choose which definition is the right one:

This is "interactive compiling", isn't it? Why not? Why the compiler
can't simply ask us, in doubt, and on response modify sources
accordingly on its own, in this case and in other similar? This would
ease the programming effort a lot.

What are your opinions on this matter?

 

[Mark B]

Hello,

I'm not a C newbie, but I'm teaching C programming (well... FIRST
programming and then C) to other guys these days and it's driving me to
some reflexions on the language.
It's not uncommon to forget a } writing code,

Very uncommon... get your students in the habit of typing the closing
brace immediately after typing the opening brace... then fill in the middle.

and at compiling time get an error 18956778 lines after the mistake

Your functions are too long ;-)

in an otherwise absolutely correct piece of code. Or, sometimes in my
journeys I got errors reported in a file, checked and found it correct,
and discovered it was caused by an error in another file. And in general,
I noted that many, if not all, error messages from the compiler are VERY
short and cryptic, while a couple of words more could sometimes help a lot
in understanding what's wrong and where, for newbies. Well, not only for
them... maybe a compiler switch --NOOB_ERR_MSGS could be very handy for
some people )

Why can't a compiler give more accurate informations about errors?
Shouldn't this save time, stress and money?

What is your question relating to the C standard? (which is the topic of
this newsgroup)

Another example: have you ever met the error line "Multiple definitions
of..."? Nope.

For example, why can't a compiler start a negotiation "on the fly" like
this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>
Choose which definition is the right one:

This is "interactive compiling", isn't it? Why not? Why the compiler can't
simply ask us, in doubt, and on response modify sources accordingly on its
own, in this case and in other similar? This would ease the programming
effort a lot.

What are your opinions on this matter?

I don't want the compiler modifying my sources on it's own!
I'd prefer to see students taught by competent teachers...
That would ease the programming effor a lot!

Mark

 

[Gordon Burditt]

I'm not a C newbie, but I'm teaching C programming (well... FIRST

programming and then C) to other guys these days and it's driving me to
some reflexions on the language.

It's not uncommon to forget a } writing code, and at compiling time get
an error 18956778 lines after the mistake, in an otherwise absolutely
correct piece of code.

The compiler doesn't know that this is where the } is missing. There
may be several other places that would also be correct code.

Or, sometimes in my journeys I got errors
reported in a file, checked and found it correct, and discovered it was
caused by an error in another file. And in general, I noted that many,
if not all, error messages from the compiler are VERY short and cryptic,
while a couple of words more could sometimes help a lot in understanding
what's wrong and where, for newbies. Well, not only for them... maybe a
compiler switch --NOOB_ERR_MSGS could be very handy for some people )

Something like changing:
undefined symbol _main
to
undefined symbol _main - Did you forget to define main()?

might help, but in many cases, the compiler error message would start
to resemble legal documents if it tried to produce a detailed message
but still reflect that the compiler DOES NOT KNOW which of many possible
mistakes you made. Even above, it may not know that main() is supposed
to be a function, not a local variable.

One example: almost every time I get a syntax error in a system-supplied
include file (not the ANSI C headers, but ones that come with the
OS), it's because I forgot to include a prerequesite header (often
<sys/types.h>) that typedef'd something *BEFORE* this header. But
the compiler never suggests: syntax error on line 115 in <sys/proc.h>,
possibly pid_t should be a typedef but isn't? In such a situation,
I wonder how many WRONG suggestions it would come up with, when an
include file really is missing but it has to guess what should have
been in it?

Why can't a compiler give more accurate informations about errors?

The compiler is not psychic. It often can't tell whether you
declared the variable with the wrong type, or forgot one level
of indirection on the reference to it.

Shouldn't this save time, stress and money?

When it guesses WRONG, it will cause stress and waste time and money.

Another example: have you ever met the error line "Multiple definitions
of..."?

For example, why can't a compiler start a negotiation "on the fly" like
this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>

Up to this point, this would be a nice message, listing all the
definitions.

Choose which definition is the right one:

How would I answer this to indicate that (3) is a typo and (2)
should have been declared static? I have not memorized where all
of the references are, so I can't say which reference should go
with which function off the top of my head. There are also ways
to answer TWO messages like that (about the same function/variable)
where my answers cannot be coded in valid C short of globally
renaming one of the functions/variables. Oh, yes, when the compiler
is compiling foo.c, it DOESN'T know that if it does a global rename
of a function, it has to fix up the references in bar.c, a bunch
of clients being developed on another computer in another country,
and the distribution disk on CD-ROM.

I don't want the compiler to try to be interactive when I'm compiling
an open-source package. Most likely the configure script is including
the wrong libraries or include files, and the message you suggest
will be entirely misleading. Also, I don't want it writing on
source code behind my back for any reason.

This is "interactive compiling", isn't it?

I want my source code to reflect the actual source code used, not
a slight approximation to it.

Why not? Why the compiler
can't simply ask us, in doubt, and on response modify sources
accordingly on its own, in this case and in other similar? This would
ease the programming effort a lot.

If the compiler modifies source code, it had darn well better use
*MY* style and ONLY *MY* style.

What are your opinions on this matter?

Clearer error messages that give more details would often help.
I think I've seen messages that complain about the type of a
variable (on a line with many variables in it) without naming the
variable in question.

Compilers modifying source code is a bad idea. The only exception
I'll make is for void main(), where the compiler should *DELETE*
the offending source code.

Gordon L. Burditt

 

[John Bode]

Why can't a compiler give more accurate informations about errors?
Shouldn't this save time, stress and money?

Why give concise and accurate messages when you can do this instead:

http://www.ralentz.com/old/mac/humor/mpw-c-errors.html

And yeah, I had to work with MPW for a while, and I got most of those
at one time or another. It got *very* old *very* quickly.

 

[akarl]

I'm not a C newbie, but I'm teaching C programming (well... FIRST
programming and then C) to other guys these days and it's driving me to
some reflexions on the language.

It's not uncommon to forget a } writing code, and at compiling time get
an error 18956778 lines after the mistake, in an otherwise absolutely
correct piece of code. Or, sometimes in my journeys I got errors
reported in a file, checked and found it correct, and discovered it was
caused by an error in another file. And in general, I noted that many,
if not all, error messages from the compiler are VERY short and cryptic,
while a couple of words more could sometimes help a lot in understanding
what's wrong and where, for newbies. Well, not only for them... maybe a
compiler switch --NOOB_ERR_MSGS could be very handy for some people ) ....
What are your opinions on this matter?

The preprocessor is the source of all evil when it comes to locating
compilation errors.

August

 

[Eric Sosman]

[...]
Why can't a compiler give more accurate informations about errors?
Shouldn't this save time, stress and money?
[...]
What are your opinions on this matter?

First, that you are well-intentioned. Second, though, that
you have but little grasp of the issues and no understanding
of the difficulties. Third, that spending some time in forums
like comp.compilers might give you some insights.

 

[Emmanuel Delahaye]

Massimo Soricetti wrote on 30/08/05 :

I'm not a C newbie, but I'm teaching C programming (well... FIRST programming
and then C) to other guys these days and it's driving me to some reflexions
on the language.

It's not uncommon to forget a } writing code, and at compiling time get an
error 18956778 lines after the mistake, in an otherwise absolutely correct
piece of code.

Yes, the very common "';' missing "error is undetected. This is due to
the C-syntax.

Or, sometimes in my journeys I got errors reported in a file,
checked and found it correct, and discovered it was caused by an error in
another file.

An include file. Yes.

And in general, I noted that many, if not all, error messages
from the compiler are VERY short and cryptic, while a couple of words more
could sometimes help a lot in understanding what's wrong and where, for
newbies. Well, not only for them... maybe a compiler switch --NOOB_ERR_MSGS
could be very handy for some people )

Note that the error messages are a part of the implementation and not
of the language itself. The language only requires 'diagnostics'.

Some compilers have very good messages (Intel, for example) but AFAIK,
there are not free (free beer).

Note also that you should only consider the first error. Setting the
compiler to stop at the first error certainely is a gain(?) of time.

Why can't a compiler give more accurate informations about errors? Shouldn't
this save time, stress and money?

Switch to Pascal !

Another example: have you ever met the error line "Multiple definitions
of..."?

Yes. It's a common design error. (object definitions in a header,
stuffs like that...)

For example, why can't a compiler start a negotiation "on the fly" like this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>
Choose which definition is the right one:

No. A design error should be fixed.

This is "interactive compiling", isn't it?

No. It's a batch process. However, some IDE's have a 'stop' button.

Why not? Why the compiler can't
simply ask us, in doubt, and on response modify sources accordingly on its
own, in this case and in other similar? This would ease the programming
effort a lot.

With a good IDE (Borland C++, VC++6, Dev-C++, Kdevelop), the process is
not far from it. You generally have an error list, you just click on
the error, and it automagically points to the error line into the
source file.

AFAIK, ol'good 'vi' and 'emacs' can do that from the earliest times...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"There are 10 types of people in the world today;
those that understand binary, and those that dont."

 

[Kenneth Brody]

Gordon Burditt wrote:
[...]

Something like changing:
undefined symbol _main
to
undefined symbol _main - Did you forget to define main()?

might help, but in many cases, the compiler error message would start
to resemble legal documents if it tried to produce a detailed message
but still reflect that the compiler DOES NOT KNOW which of many possible
mistakes you made. Even above, it may not know that main() is supposed
to be a function, not a local variable.

BTDT. There was a FORTRAN compiler at the school I went to, specifically
designed for the FORTRAN class projects. It ran extremely fast, but
produced extremely poor code. This made sense as it would take numerous
compiles before the code would compile error-free, and the executable
would only be run once. (In other words, any time spent trying to
optimize the output code would exceed the time saved in running it.)

Being aimed at those learning FORTRAN, its error message were _very_
verbose. As in a missing comma might generate half a page of text
describing what you "might" have meant.

One example: almost every time I get a syntax error in a system-supplied
include file (not the ANSI C headers, but ones that come with the
OS), it's because I forgot to include a prerequesite header (often
<sys/types.h>) that typedef'd something *BEFORE* this header. But
the compiler never suggests: syntax error on line 115 in <sys/proc.h>,
possibly pid_t should be a typedef but isn't? In such a situation,
I wonder how many WRONG suggestions it would come up with, when an
include file really is missing but it has to guess what should have
been in it?

The above-mentioned FOTRAN compiler would have listed them all.

[...]

Up to this point, this would be a nice message, listing all the
definitions.

FYI - My C compiler does list the file/line which first defined the
variable/prototype.

[...]

If the compiler modifies source code, it had darn well better use
*MY* style and ONLY *MY* style.

I don't want the compiler modifying my source any more than I want
Windows' chkdsk to "automatically fix errors".

Now, bringing up the source in a text editor, letting me fix it, and
then restarting the compile might be a nice thing. However, the
"interactive development environment" of the compiler I usually use
lets me double-click on an error message, and it brings up the
corresponding source file, with the cursor on the line which gave
the error. And, I can do that for each error that it gave, without
having to restart until I'm done.

Clearer error messages that give more details would often help.
I think I've seen messages that complain about the type of a
variable (on a line with many variables in it) without naming the
variable in question.

Compilers modifying source code is a bad idea. The only exception
I'll make is for void main(), where the compiler should *DELETE*
the offending source code.

Perhaps "i = i++;" should result in the entire file being replaced with
ASCII-art of nasal demons?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Ben Pfaff]

Another example: have you ever met the error line "Multiple
definitions of..."?

For example, why can't a compiler start a negotiation "on the fly"
like this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>
Choose which definition is the right one:

Perhaps you should start doing all of your programming in TeX.
It will indeed give you this kind of a prompt when it encounters
an error in your source file. (However, TeX is not a very good
language for general programming.)

 

[Malcolm]

Why can't a compiler give more accurate informations about errors?
Shouldn't this save time, stress and money?

Try to write a front end to a C compiler that checks the source for
correctness (but doesn't actually produce any executable).
You'll soon find that there are many difficulties. However it is certainly
possible to do a better job than most compliers in catching errors.
Maybe you could design a language with a syntax that is easier to parse,
given that the human programmer will probably have made human-type errors. I
don't think anyone has considered this issue seriously in language design.

This is "interactive compiling", isn't it? Why not? Why the compiler can't
simply ask us, in doubt, and on response modify sources accordingly on its
own, in this case and in other similar? This would ease the programming
effort a lot.

That's a nightmare. Like the Microsoft car that turns the steering wheel for
you every time you put the indicators on and apply the brake. It tests it's
really fun, until you try to overtake someone on the motorway. You put on
the indicator, and press the accelerator. At the that point a child playing
chicken runs across the road, and you have to brake sharply.

 

[Joseph S.]

I dont know the technical reasons for it, but, the Eclipse Integrated
Development Environment (www.eclipse.org) for Java does things a little
like this -suggesting at coding time what could be wrong with your
code, giving alternatives on a popup textbox to change the type of your
variable,. to add a cast here, to remove a line there etc.- It is not
complete/foolproof, neither does it claim to be, but for most beginner
to intremediate level Java coders it is useful, (of course, it is for
the java language) It immediately suggests what could be wrong with
your code -So, looking at this proficiency of Eclipse in Java, one
wonders whether some of that kind of "interactive" coding can be
brought to C. Most Importantly, Eclipse also has a fully functional C
development package which you can get separately from their site. It is
all free for any purpose. You may want to look at it. But of course,
Java is very different (OOP, no header files, no need to think about
inclusion order, lot of things..... ) Whether Java is better or not is
not the topic of this group, but such a thing as intelligent support
for coding exists in Eclipse and is very useful.

 

[jacob navia]

Hello,


It's not uncommon to forget a } writing code, and at compiling time get
an error 18956778 lines after the mistake, in an otherwise absolutely
correct piece of code.

This can be efficiently handled in the IDE (Integrated development
Environment).

In the IDE of lcc-win32, when you save a file, the IDE will check for
1) mismatched braces, parentheses and brackets
2) Syntax errors
3) Mismtached #if/#ifdef

In the case of mismatched braces it will keep stack of positions
of opening braces and in most cases it will be able to tell you
where the opening brace is that it is mismatched.

I do not think that this is the job of the compiler itself but it is
the job of the environment where you build your programs.

Or, sometimes in my journeys I got errors
reported in a file, checked and found it correct, and discovered it was
caused by an error in another file. And in general, I noted that many,
if not all, error messages from the compiler are VERY short and cryptic,
while a couple of words more could sometimes help a lot in understanding
what's wrong and where, for newbies.

This is true, and the lcc-win32 system tries to give as detailed and
clear error messages as possible? For instance it avoids:
lvalue required

and it says

the left hand side can't be assigned to,
what is (in my opinion) much clearer.

Contrary to many people around, I find that your messages has a very
valid reason, and I think it is useful.

Well, not only for them... maybe a

compiler switch --NOOB_ERR_MSGS could be very handy for some people )

Why can't a compiler give more accurate informations about errors?
Shouldn't this save time, stress and money?

In many cases this is very hard. Error analysis is quite
difficult, specially when a missing right brace can completely
change the meaning of the program...

Another example: have you ever met the error line "Multiple definitions
of..."?

For example, why can't a compiler start a negotiation "on the fly" like
this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>
Choose which definition is the right one:

This is "interactive compiling", isn't it? Why not? Why the compiler
can't simply ask us, in doubt, and on response modify sources
accordingly on its own, in this case and in other similar? This would
ease the programming effort a lot.

I think this is out of the question. It is not possible to leave a
blatant error in the source code like that, and compiling anyway.

Suppose you said: I want the option 3.

Then you compile, ship the program, and several months later you wonder
My program is crashing but I forgot which option I typed in when the
compiler asked damm. Which one should I debug now?????

jacob

lcc-win32: a compiler system for windows
http://www.cs.virginia.edu/~lcc-win32

 

[Gordon Burditt]

This can be efficiently handled in the IDE (Integrated development

Environment).

In the IDE of lcc-win32, when you save a file, the IDE will check for
1) mismatched braces, parentheses and brackets
2) Syntax errors
3) Mismtached #if/#ifdef

Does this mean I can't save the program until I've finished typing
it in? I don't generally like leaving unsaved changes in an editor
more than a couple of minutes. And I may not want to finish up the
statement I'm in the middle of typing in when the phone is ringing
or when my boss is calling me into a meeting. That goes triple
when the UPS starts beeping and I know I don't have much time left
until the computer loses power.

In the case of mismatched braces it will keep stack of positions
of opening braces and in most cases it will be able to tell you
where the opening brace is that it is mismatched.

I do not think that this is the job of the compiler itself but it is
the job of the environment where you build your programs.

Gordon L. Burditt

 

[Massimo Soricetti]

Eric Sosman ha scritto:

First, that you are well-intentioned. Second, though, that
you have but little grasp of the issues and no understanding
of the difficulties. Third, that spending some time in forums
like comp.compilers might give you some insights.

Mmm nice clue...

 

[Massimo Soricetti]

Joseph S. ha scritto:

I dont know the technical reasons for it, but, the Eclipse Integrated
Development Environment (www.eclipse.org) for Java does things a little
like this -suggesting at coding time what could be wrong with your
code, giving alternatives on a popup textbox to change the type of your
variable,. to add a cast here, to remove a line there etc.- It is not
complete/foolproof, neither does it claim to be, but for most beginner
to intremediate level Java coders it is useful, (of course, it is for
the java language) It immediately suggests what could be wrong with
your code -So, looking at this proficiency of Eclipse in Java, one
wonders whether some of that kind of "interactive" coding can be
brought to C.

So, something in this field CAN actually be done... Even if some of my
ideas had proven naive, I think that a C "pre-preprocessor" looking for
errors and making some guess based on coding style (detected from
sources: every programmer has his own coding style, the prepreprocessor
should be able to examinate code and detect kind of indentation, of
parentheses placement etc) and common error sources and tries to suggest
possible causes could eventually be useful...

 

[Chris Hills]

Hello,

I'm not a C newbie, but I'm teaching C programming (well... FIRST
programming and then C) to other guys these days and it's driving me to
some reflexions on the language.

It's not uncommon to forget a } writing code, and at compiling time get
an error 18956778 lines after the mistake, in an otherwise absolutely
correct piece of code. Or, sometimes in my journeys I got errors
reported in a file, checked and found it correct, and discovered it was
caused by an error in another file. And in general, I noted that many,
if not all, error messages from the compiler are VERY short and cryptic,
while a couple of words more could sometimes help a lot in understanding
what's wrong and where, for newbies. Well, not only for them... maybe a
compiler switch --NOOB_ERR_MSGS could be very handy for some people )

Why can't a compiler give more accurate informations about errors?

Because a C compiler is a translator. Not an error checker. It tries to
make the most complex statement it can from the tokens.

For error checking use Lint. that is whit it is designed for.

Shouldn't this save time, stress and money?

Lint will. Why aren't you using it? If you are teaching C you should be
using Lint as part of the system.

Another example: have you ever met the error line "Multiple definitions
of..."?

For example, why can't a compiler start a negotiation "on the fly" like
this:

You write the compiler to do it then?

This is "interactive compiling", isn't it? Why not? Why the compiler
can't simply ask us, in doubt, and on response modify sources
accordingly on its own,

CERTAINLY NOT....

in this case and in other similar? This would
ease the programming effort a lot.

What are your opinions on this matter?

You should it right not look for an easy way of apparently auto-
correcting errors.

1 more care when programming.
2 Use lint
3 run lint OFTEN (or even use the compiler often) every few lines. that
way you catch errors when they appear.
4 short functions that can be unit tested individually (with stubs if
required

5The above is basic programming. If you don't know that should you be
teaching?

 

[Massimo Soricetti]

Chris Hills ha scritto:

You should it right not look for an easy way of apparently auto-
correcting errors.

1 more care when programming.

Mmmm if care is all we need, why aren't we all using MASM to write
programs? :-|

2 Use lint

(...scribble scribble on notepad...)

5The above is basic programming. If you don't know that should you be
teaching?

The point is, I'm the best teacher here. Or, the best teacher my boss
want to hire... I'm training two colleagues.

 

[Eric Sosman]

Joseph S. ha scritto:



So, something in this field CAN actually be done... Even if some of my
ideas had proven naive, I think that a C "pre-preprocessor" looking for
errors and making some guess based on coding style (detected from
sources: every programmer has his own coding style, the prepreprocessor
should be able to examinate code and detect kind of indentation, of
parentheses placement etc) and common error sources and tries to suggest
possible causes could eventually be useful...

Source code editors can be a help with some of the kinds
of errors you've mentioned. My editor of choice is Emacs, but
it's not the only one capable of matching up parentheses and
braces and brackets -- and this can stamp out a lot of silly
errors before the compiler even comes onto the scene. If you're
typing along and suddenly Emacs auto-indents a line in a way you
didn't expect, you become aware right away that you've forgotten
a } or have too many ('s or some such. If you write something
like `y = f(x[i)]' the editor will complain as soon as the )
appears. Simple level-counting like this can be fooled (especially
by the preprocessor), but is surprisingly effective at preventing
bugs before they get written.

Fancier features like automatic code completion -- well, it's
a matter of taste, I guess, but I personally don't like 'em. They
distract me by interrupting my flow of thought, they annoy me by
popping up their lists of suggestions right in front of the nearby
piece of code I'm staring at, they guess wrong as often as right.
(One such that I particularly disliked just didn't want me to write
a reset() function. Every time I typed r followed by e, the damned
thing would triumphantly supply t u r n and then sit there smirking
while I cleaned up the mess.) Some people may like this brand of
assistance; I'm not among them.

Editors that use built-in pieces of compilers can be helpful
if you can moderate their puppy-like eagerness to write your code
for you and chew on your slippers. For Java I use NetBeans, and
although it's far too face-licking and tail-wagging for my taste
I must admit it's nice to have a red squiggle appear when I call
isWhiteSpace() instead of isWhitespace(). I don't know whether
there are C-based tools that do this sort of thing (the separate
compilation model and the preprocessor could make things hard),
but I haven't looked. Seek, and ye may find.

 

[Richard Tobin]

[wants a more helpful compiler]

There have been compilers like this, though I haven't seen one for C.

The most famous example was PLICC, the IBM PL/1 Checkout Compiler.
It would insert semicolons, guess at missing declarations, and so on.
It could take a FORTRAN program and "fix" it until it was a legal PL/1
program (not all FORTRAN programs of course, but sufficiently simple
ones).

It worked quite well for users who were writing simple programs and whose
errors were ones of the kind it could fix - simple syntax errors and the
like.

As I remember, experienced users didn't use it much, and those who did
didn't generally let it fix the errors itself.

There's no need for such a program to be a real compiler (that is, one
that generates code). It can be a checker that you run separately or
that some other compiler runs for you when there's an error. The
traditional C tool "lint" was a bit like this: it did't fix your
files, but it attempted to do more comprehensive checking of your code
than most compilers did.

-- Richard

 

[Ed Vogel]

As other replies have pointed out, many development environments
provide the functionality you request.

I think another reason is that producing error messages is not considered
a "sexy" part of a compiler. Most compiler writers worry about things
such as code optimization. If you look at most books on writing compilers,
and especially if you look at technical papers, generation of efficient
code is the main topic. I bet you'll find very few PhD theses written

It's not uncommon to forget a } writing code, and at compiling time get an
error 18956778 lines after the mistake, in an otherwise absolutely correct
piece of code.

The compiler I work on will attempt to detect the { that was missing a
close brace.

And in general, I noted that many, if not all, error messages from the
compiler are VERY short and cryptic, while a couple of words more could
sometimes help a lot in understanding what's wrong and where, for newbies.

Our compiler's message tend to be rather long. In fact we sometimes get
feedback saying they are too long. For example, here's something that
gets posted to this newsgroup all the time. Consider the program:

void bar(int a, int b);
int x;
void f(void) {
bar(x++,x++);
}

lint will emit:
"t.c", line 4: warning: x evaluation order undefined

Our compiler's message is:

bar(x++,x++);
....1
(1) Warning: In this statement, the expression "bar(...)" modifies the
variable
"x" more than once without an intervening sequence point.
This behavior is undefined. (undefvarmod)

Well, not only for them... maybe a compiler switch --NOOB_ERR_MSGS could
be very handy for some people )

We can do this too...if you add the -verbose switch you'll see:


bar(x++,x++);
....1
(1) Warning: In this statement, the expression "bar(...)" modifies the
variable
"x" more than once without an intervening sequence point.
This behavior is undefined. (undefvarmod)

Description: The compiler has detected a case where the same variable
has been modified more than once in an expression without a sequence
point between the modifications. Because what modification will occur
last is not defined, this expression might produce different results on
different platforms.
User Action: Rewrite the expression so that each variable is modified
only once.

Is this enough??

Why can't a compiler give more accurate informations about errors?

Because most compiler writers are paid to have their compilers generate
better code.

Shouldn't this save time, stress and money?

Yes...I think it would. Have you written to your compiler supplier and
requested better messages?

Ed Vogel
HP C for OpenVMS and Tru64 UNIX Engineering.