Re: Improved C warning messages

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

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