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

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 :o)

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?

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

"Massimo Soricetti" <massimo_main@hotmail.com> wrote in message
news:IM%Qe.120733$fm.7885188@news4.tin.it...[color=blue]
> 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,[/color]
Very uncommon... get your students in the habit of typing the closing
brace immediately after typing the opening brace... then fill in the middle.
[color=blue]
> and at compiling time get an error 18956778 lines after the mistake[/color]
Your functions are too long ;-)
[color=blue]
> 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 :o)
>
> Why can't a compiler give more accurate informations about errors?
> Shouldn't this save time, stress and money?[/color]
What is your question relating to the C standard? (which is the topic of
this newsgroup)
[color=blue]
> Another example: have you ever met the error line "Multiple definitions
> of..."?[/color]
Nope.
[color=blue]
> 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?[/color]
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

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

>I'm not a C newbie, but I'm teaching C programming (well... FIRST[color=blue]
>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.[/color]

The compiler doesn't know that this is where the } is missing. There
may be several other places that would also be correct code.
[color=blue]
>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 :o)[/color]

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?
[color=blue]
>Why can't a compiler give more accurate informations about errors?[/color]

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.
[color=blue]
>Shouldn't this save time, stress and money?[/color]

When it guesses WRONG, it will cause stress and waste time and money.
[color=blue]
>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...>[/color]

Up to this point, this would be a nice message, listing all the
definitions.
[color=blue]
>Choose which definition is the right one:[/color]

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.
[color=blue]
>This is "interactive compiling", isn't it?[/color]

I want my source code to reflect the actual source code used, not
a slight approximation to it.
[color=blue]
>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.[/color]

If the compiler modifies source code, it had darn well better use
*MY* style and ONLY *MY* style.
[color=blue]
>What are your opinions on this matter?[/color]

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

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

Massimo Soricetti wrote:
[color=blue]
> Why can't a compiler give more accurate informations about errors?
> Shouldn't this save time, stress and money?
>[/color]

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.

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

Massimo Soricetti wrote:[color=blue]
> 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 :o)[/color]
....[color=blue]
> What are your opinions on this matter?[/color]

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

August

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

Massimo Soricetti wrote:[color=blue]
> [...]
> 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?[/color]

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.

--
Eric.Sosman@sun.com

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

Massimo Soricetti wrote on 30/08/05 :[color=blue]
> 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.[/color]

Yes, the very common "';' missing "error is undetected. This is due to
the C-syntax.
[color=blue]
> 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.[/color]

An include file. Yes.
[color=blue]
> 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 :o)[/color]

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.
[color=blue]
> Why can't a compiler give more accurate informations about errors? Shouldn't
> this save time, stress and money?[/color]

Switch to Pascal !
[color=blue]
> Another example: have you ever met the error line "Multiple definitions
> of..."?[/color]

Yes. It's a common design error. (object definitions in a header,
stuffs like that...)
[color=blue]
> 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:[/color]

No. A design error should be fixed.
[color=blue]
> This is "interactive compiling", isn't it?[/color]

No. It's a batch process. However, some IDE's have a 'stop' button.
[color=blue]
> 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.[/color]

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."

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

Gordon Burditt wrote:
[...][color=blue][color=green]
> >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 :o)[/color]
>
> 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.[/color]

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.
[color=blue]
> 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?[/color]

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

[...][color=blue][color=green]
> >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...>[/color]
>
> Up to this point, this would be a nice message, listing all the
> definitions.[/color]

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

[...][color=blue][color=green]
> >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.[/color]
>
> If the compiler modifies source code, it had darn well better use
> *MY* style and ONLY *MY* style.[/color]

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.
[color=blue][color=green]
> >What are your opinions on this matter?[/color]
>
> 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.[/color]

:-)

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:ThisIsASpamTrap@gmail.com>

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

Massimo Soricetti <massimo_main@hotmail.com> writes:
[color=blue]
> 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:[/color]

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.)
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

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

"Massimo Soricetti" <massimo_main@hotmail.com> wrote[color=blue]
>
> Why can't a compiler give more accurate informations about errors?
> Shouldn't this save time, stress and money?
>[/color]
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.[color=blue]
>
> 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.
>[/color]
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.[color=blue]
>
> What are your opinions on this matter?
>[/color]

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

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.

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

Massimo Soricetti wrote:[color=blue]
> 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.[/color]

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.

[color=blue]
> 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.[/color]

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[color=blue]
> compiler switch --NOOB_ERR_MSGS could be very handy for some people :o)
>
> Why can't a compiler give more accurate informations about errors?
> Shouldn't this save time, stress and money?
>[/color]

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...
[color=blue]
> 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.
>[/color]

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

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

>This can be efficiently handled in the IDE (Integrated development[color=blue]
>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[/color]

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.
[color=blue]
>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.[/color]

Gordon L. Burditt

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

Eric Sosman ha scritto:[color=blue]
>
> 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.[/color]

Mmm nice clue... :-)

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

Joseph S. ha scritto:
[color=blue]
> 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.[/color]

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...

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

In article <IM%Qe.120733$fm.7885188@news4.tin.it>, Massimo Soricetti
<massimo_main@hotmail.com> writes[color=blue]
>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 :o)
>
>Why can't a compiler give more accurate informations about errors?[/color]

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.
[color=blue]
>Shouldn't this save time, stress and money?[/color]

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

[color=blue]
>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:[/color]

You write the compiler to do it then?
[color=blue]
>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,[/color]

CERTAINLY NOT....
[color=blue]
> in this case and in other similar? This would
>ease the programming effort a lot.
>
>What are your opinions on this matter?[/color]


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?


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

Chris Hills ha scritto:[color=blue]
> You should it right not look for an easy way of apparently auto-
> correcting errors.
>
> 1 more care when programming.[/color]

Mmmm if care is all we need, why aren't we all using MASM to write
programs? :-|
[color=blue]
> 2 Use lint[/color]

(...scribble scribble on notepad...)
[color=blue]
> 5The above is basic programming. If you don't know that should you be
> teaching?[/color]

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

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

Massimo Soricetti wrote:[color=blue]
> Joseph S. ha scritto:
>[color=green]
>> 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.[/color]
>
>
> 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...[/color]

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[i] = 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.

--
Eric Sosman
esosman@acm-dot-org.invalid

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

In article <IM%Qe.120733$fm.7885188@news4.tin.it>,
Massimo Soricetti <massimo_main@hotmail.com> wrote:
[color=blue]
> [wants a more helpful compiler][/color]

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

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

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
on compiler diagnostic, but many many writen on optimizations.

With that said, to address some of your specific issues:
[color=blue]
> 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.[/color]

The compiler I work on will attempt to detect the { that was missing a
close brace.
[color=blue]
> 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.[/color]

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)
[color=blue]
> Well, not only for them... maybe a compiler switch --NOOB_ERR_MSGS could
> be very handy for some people :o)[/color]

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??
[color=blue]
> Why can't a compiler give more accurate informations about errors?[/color]

Because most compiler writers are paid to have their compilers generate
better code.
[color=blue]
> Shouldn't this save time, stress and money?[/color]

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.

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

Chris Hills <chris@phaedsys.org> writes:[color=blue]
> In article <IM%Qe.120733$fm.7885188@news4.tin.it>, Massimo Soricetti
> <massimo_main@hotmail.com> writes[color=green]
>>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 :o)
>>
>>Why can't a compiler give more accurate informations about errors?[/color]
>
> 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.[/color]
[...]

A compiler is both a translator and an error checker. A conforming C
compiler is required by the standard to issue diagnostics for certain
classes of errors; the diagnostics aren't required to be useful, but
in any decent compiler they will be.

The decision to make lint a separate tool from the compiler is an old
historical one. I don't know much about what went into that decision,
but I suspect it had to do with resource limits on the machines of the
time, limits that are no longer relevant.

There are still various lint-like tools floating around, and it's
still a good idea to use them, but there's no inherent reason why the
compiler itself shouldn't be doing what lint does, at least
optionally. Most C compilers will issue warnings for perfectly legal
code; this is, in my opinion, a good thing. gcc, for example, will
warn about unused or potentially unitialized variables, incorrect
printf format strings, and a number of other things.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

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

richard@cogsci.ed.ac.uk (Richard Tobin) writes:[color=blue]
> In article <IM%Qe.120733$fm.7885188@news4.tin.it>,
> Massimo Soricetti <massimo_main@hotmail.com> wrote:
>[color=green]
>> [wants a more helpful compiler][/color]
>
> 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).[/color]

I've worked on a compiler (not a C compiler) that did agressive syntax
fix-up on syntactically incorrect input. If you fed it a paragraph of
English text, it would find English words that happened to be keywords
and eventually fit them into a transformed version of the input that
happened to be a legal program. (Sometimes this would be an empty
compilation unit.)

This was useful because it meant that a syntax error wouldn't prevent
the compiler from continuing to detect further errors. A missing
semicolon on line 50 would be re-inserted, and the compiler would
still detect the misspelled identifier on line 200.

*But* all this transformation was purely internal. Once a syntax
error was detected, the compilation was going to fail; the fix-up was
done only to allow further error detection. It would *never* attempt
to modify the input source file, or even generate a corrected one;
you'd have to insert the semicolon yourself.

With today's faster systems, it's not clear that this is worth the
effort. If a compiler detects a syntax error and immediately bails
out, I can fix the error and recompile to detect any subsequent
errors.

Another useful trick I've seen (in a different compiler) is using
indentation as a clue for error recovery. For example, if you have a
C program like this:

int main(void)
{ /* line 2 */
if (something) { /* line 3 */
do_something();
/* line 5, missing right brace */
} /* line 6 */

most compilers will match the '{' on line 3 to the '}' on line 6, and
complain about a missing '}' following that. A compiler that pays
attention to indentation might correctly report a missing '}' on
line 5. In a larger program, that might save the user a lot of time
tracking down the error.

All this stuff is a lot of work for whoever writes the parser, to
avoid what's usually not a lot of work for the programmer to find and
fix the error. Again, it's not obvious whether it's worth the effort.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

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

In article <lnek89q1tx.fsf@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes[color=blue]
>Chris Hills <chris@phaedsys.org> writes:[color=green]
>> In article <IM%Qe.120733$fm.7885188@news4.tin.it>, Massimo Soricetti
>> <massimo_main@hotmail.com> writes[color=darkred]
>>>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 :o)
>>>
>>>Why can't a compiler give more accurate informations about errors?[/color]
>>
>> 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.[/color]
>[...]
>
>A compiler is both a translator and an error checker. A conforming C
>compiler is required by the standard to issue diagnostics for certain
>classes of errors; the diagnostics aren't required to be useful, but
>in any decent compiler they will be.
>
>The decision to make lint a separate tool from the compiler is an old
>historical one. I don't know much about what went into that decision,
>but I suspect it had to do with resource limits on the machines of the
>time, limits that are no longer relevant.
>
>There are still various lint-like tools floating around, and it's
>still a good idea to use them, but there's no inherent reason why the
>compiler itself shouldn't be doing what lint does, at least
>optionally. Most C compilers will issue warnings for perfectly legal
>code; this is, in my opinion, a good thing. gcc, for example, will
>warn about unused or potentially unitialized variables, incorrect
>printf format strings, and a number of other things.[/color]

I think lint was intended to be part of the compiler chain. (ask the
other Keith :-) In those day the compiler was a three pass affair so it
would have been

lint, pre-processor, cc1, cc2, cc3, assemble, link.

These days it is compile (to object )-link

So I think they may have intended lint to be part of the system. The
first Lint was first done by Johnson a year or so after the first C
compilers AFAIK) It is still AFAIK part of most Unix and Linux c
compiler suites. It just seem to have dropped of the PC ones.

I think the reason why I like a separate lint is because a different
mind-set has made it compared to the compiler. So you should between
them catch most things. It is like using two different virus scanners
with 95% coverage to get 99% coverage.

The idea of lint was to warn about legal but dubious uses of C.

this comes back the original comment that C is a s safe as any other
language when used properly . 61508 says C is OK when used with a subset
and static analysis as part of the process.

As we have seen Ada can be just as unsafe if not fully tested. The first
thing I have seen done on Modula 2 developments is the system and
pointers included. Others seemed to think if the compiler compiled it
with no bugs it was Good Code.

A few minutes with lint on code that compiles clean should convince
anyone that just because code is legal does not mean it is safe. In any
language.



--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

Chris Hills <chris@phaedsys.org> writes:
[...][color=blue]
> I think lint was intended to be part of the compiler chain. (ask the
> other Keith :-) In those day the compiler was a three pass affair so it
> would have been
>
> lint, pre-processor, cc1, cc2, cc3, assemble, link.
>
> These days it is compile (to object )-link[/color]

Um, what other Keith are you referring to? Do you mean Ken Thompson?

As far as I know, lint has always been optional. The chain above
implies that the output of lint would be fed to the preprocessor;
that's not how it works.

[...]
[color=blue]
> As we have seen Ada can be just as unsafe if not fully tested. The first
> thing I have seen done on Modula 2 developments is the system and
> pointers included. Others seemed to think if the compiler compiled it
> with no bugs it was Good Code.
>
> A few minutes with lint on code that compiles clean should convince
> anyone that just because code is legal does not mean it is safe. In any
> language.[/color]

Since lint applies only to C (or perhaps, in more recent variants, to
C++), this should at most convince someone that legal C code isn't
necessarily safe.

There is no language in which it is impossible, or even particularly
difficult, to write bad code. But there are languages in which a
clean compilation can imply you're much further along the path to a
correct program than is the case in other languages. I won't go into
more specifics than that because I don't want to start a language war
-- but I will mention that improving C in this respect would be a
worthy goal. The introduction of prototypes, for example, was a great
improvement. I'd be surprised if there weren't more opportunities for
such improvements.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

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

> It's not uncommon to forget a } writing code

If by chance you happen to write your code on the Windows platform then
you could use something like the Zeus IDE. It has several features that
would help in situations like this, for example:

1: Automatic Brace Insertion
This means when you enter this code:
{<- Enter key here

Zeus will automatically do this:
{
|<- Cursor here
}

2: Code folding
Since code folding is done on braces, if a brace is missing the code
folding quickly highlights that something is wrong.

3: Find Matching Braces.
Searching for a matching brace also helps find missing braces.
[color=blue]
> And in general, I noted that many, if not all, error messages
> from the compiler are VERY short and cryptic,[/color]

With time things do become clearer. I would suggest taking careful note
of the exact wording of the compile error. Then when you fix the error
go back and revisit the compiler error message.

On most occasions I think you will find the compiler error message was
in fact valid and precise.

The compiler output is a lot like a legal document. Consider a legal
document that is impossible to read. But to a lawyer the same document
is accurate and precise.

To better understand the compiler you just need to practice your
compiler legal speak :)
[color=blue]
> Why can't a compiler give more accurate informations about
> errors?[/color]

In general they do.
[color=blue]
> Shouldn't this save time, stress and money?[/color]

After time you will find the stress is not created by the compiler or
it error message it produces, but rather the tight deadlines and that
strange program crash that is proving impossible to track down.

Jussi Jumppanen
Author: Zeus for Windows
Note: Zeus is shareware (45 day trial).