Improved C warning messages

"Tzvetan Mikov" <mikov@usa.net>
22 Apr 1999 02:30:50 -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)
[1 later articles]
| List of all articles for this month |

From: "Tzvetan Mikov" <mikov@usa.net>
Newsgroups: comp.compilers
Date: 22 Apr 1999 02:30:50 -0400
Organization: Posted via RemarQ Communities, Inc.
Keywords: C, errors, question

Hello,
I am developing an ANSI C compiler and here is a problem I stumbled upon
recently. It is not of great importance for the code generation, but it is
interesting and I would appreciate any ideas or pointers for a clean
solution.
The compiler should generate as detailed warning messages as possible -
however I am trying not to generate meaningless warnings because in that
case the user will ignore all of them anyway :-)


Here is an example (it is taken from a discussion in another newsgroup):


      unsigned short c;
      unsigned short d;
      ...
      d = c >> 8; // warning: assigning int to short


We assume that we targeting a CPU where "short" is 16-bit wide and
"int" is 32-bit wide. All the compilers I have checked (VC and
BCBuilder) produce a warning about assigning an int value to
short. The basic reason behind this is obvious (_c_ is promoted to
"int" and this is the result type of the >> operation), however in
this case the warning is meaningless because there is no way an
"unsigned short" value will actually overflow to "int" when it is
being shifted to the right. Note however that if _c_ was "signed
short", the warning would be correct because after sign expansion _c_
might have significant bits in its high-order word.


I am attempting to avoid such warnings and other similar to this one. For
example:
        unsigned u;
        short s;
        ....
        s = u >> 16; // must not produce warning about assigning int to short


If the shift count was 15, the warning would be completely relevant however.


The task gets a little more complicated because so far I have
abstracted the front end from the target CPU. It operates with
variable type sizes (e.g. "int" might be or might not be equal to
"long", etc.) It gets even more interesting if signed and unsigned
bitfields are involved.


regards,
Tzvetan


Post a followup to this message

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