Re: Improved C warning messages

"Tzvetan Mikov" <mikov@usa.net>
29 Apr 1999 00:45:59 -0400

          From comp.compilers

Related articles
Improved C warning messages mikov@usa.net (Tzvetan Mikov) (1999-04-22)
Re: Improved C warning messages jejones@microware.com (James Jones) (1999-04-26)
Re: Improved C warning messages gopi@sankhya.com (1999-04-26)
Re: Improved C warning messages rinie4384@my-dejanews.com (1999-04-26)
Re: Improved C warning messages fjh@cs.mu.OZ.AU (1999-04-29)
Re: Improved C warning messages mikov@usa.net (Tzvetan Mikov) (1999-04-29)
Re: Improved C warning messages mikov@usa.net (Tzvetan Mikov) (1999-04-29)
Re: Improved C warning messages saroj@bear.com (1999-04-30)
| List of all articles for this month |

From: "Tzvetan Mikov" <mikov@usa.net>
Newsgroups: comp.compilers
Date: 29 Apr 1999 00:45:59 -0400
Organization: Posted via RemarQ Communities, Inc.
References: 99-04-080 99-04-093
Keywords: C, errors

rinie4384@my-dejanews.com wrote
>You can solve this by letting the frontend know the int size as a
>parameterised table (so that you can repress warnings when int and
>longs or int and shorts are the same type) LCC has this kind of
>frontend/backend coupling.


You are right. For some time I was enjoying the idea of having a
completely target-independant front end, I was even planning to keep
it in a separate dynamic-link module that wouldn't change for
different targets. Lately however, I have come to the conclusion that
this is a complication that isn't justified. Now the front end has
full compile-time knowledge of all type sizes - this allows it even to
perform some simple optimizations.


>
>[..]
>This type of code is often used for more low level programming. Why
>not let the programmer state to the compiler that he knows that the
>results fits in a short: s = (unsigned short)(u >> 16);


Well, I believe this is a common short-coming of many compilers. If
60% of the warnings are useless, or if they force me to "bloat" my
code, I turn them off and miss the 40% that are quite necessary. Of
course generating perfect warnings is not my primary goal (I'd say at
this stage ANSI C compliance is), but I have to deal with them anyway
relatively early in the design of the compiler.


One of the problems is that I, as a relatively experienced C
programmer, don't need many of the warnings (for example about the
priorities of "<<" and "+") and tend to ignore them. As a result my
compiler reflects my programming style and would issue only warnings
that are only relevant to me; I am trying to prevent that.


>Just like you suppress unused paramer warnings with
>(void)a;


I guess, there is no way to avoid that one ;-)


regards,
Tzvetan


Post a followup to this message

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