Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpcc05!hp-ptp!marcb
From: marcb@hp-ptp.HP.COM (Marc Brandis)
Newsgroups: comp.os.msdos.programmer
Subject: Re: C error handling
Message-ID: <10850003@hp-ptp.HP.COM>
Date: 28 Sep 90 00:41:06 GMT
References: <1990Sep21.100838.9162@monu6.cc.monash.edu.au>
Organization: HP Pacific Technology Park - Sunnyvale, Ca.
Lines: 59


>I just read the discussions in this group and thought I'd add my two cents
>worth.  It relates to the C compiler's response to various types of errors
>and an error handling mechanism at runtime.

>One of the most common errors made (by me especially), is to have one too many
>open braces in some function definition, resulting in spurious error messages
>through the rest of the module.  This is especially frustrating to novice C
>programmers, confused by the compilers erratic behaviour.  I'm sure tthere are
>many more tales of horror along this line.

>Problems like this occur because of the context-sensitivity of parts of the
>language.  The compiler can get completely out of synch in certain cases,
>resulting in cryptic, uncomprehensible and irrelevant error messages.

>While some of this behaviour is undoubtedly implementation-dependent (Turbo-C's
>error messages are much more useful than Microsoft's), some is a result of the
>language definition (such as the brace business above).

>A simple solution might be to add two optional reserved words to the 
>language -- 'function' and 'procedure' (synonymous with a void function).
You seem to have stepped in one of the many holes new C programmers step
into. However, the reason for these problems is not only the fact that
there are some context-sensitive parts in the C definition, but that 
there is no "real grammar" at all. You cannot parse C with either one
of the two standard parsing methods: recursive descent which parses
LL(1) grammars or LR(1)-parsers. You have to use LR(1)-tools like
yacc and kludge them to resolve some parsing conflicts to the definition
of C and to handle lots of cases in the right way (creating context).
Part of the problem are the very complicated precedence rules in C.

But the problem will not be solved by adding synchronization points,
as the real problem is not the error messages created by the compiler.
Assume that you not only forget a closing brace, but that you also
delete by error an opening brace, as in the following example.

for (........) {
    stat1;
    if (......) {
	while (.....) {
	      stat2;
	      stat3;
        }
}

Here, the closing brace of the if-statement is missing. Now assume
that the opening brace of the for-statement gets lost by some
editing. Then this code sequence is perfectly acceptable for the
compiler, but it does not do what you expect. Actually, I remember
somebody telling me that he his found such an error in a very popular
benchmark, causing it to execute only part of a loop and screwing up
the results significantly.

I do not think that these problems can be solved by adding some
features to C (maybe by removing some). If you want to avoid these
problems, avoid C and use languages like Modula-2 or Ada.


mine has found