Bug 313815 (MONO53974) - [PATCH] We do not report CS0652 warnings (Comparison to integral constant is useless)
Summary: [PATCH] We do not report CS0652 warnings (Comparison to integral constant is ...
Status: RESOLVED FIXED
Alias: MONO53974
Product: Mono: Compilers
Classification: Mono
Component: C# (show other bugs)
Version: unspecified
Hardware: Other All
: P3 - Medium : Enhancement
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-06 17:31 UTC by Sebastien Pouliot
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
CS0562.cs (169 bytes, text/plain)
2004-02-06 17:32 UTC, Thomas Wiest
Details
proposed fix (3.52 KB, patch)
2005-08-23 22:49 UTC, Thomas Wiest
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 18:26:44 UTC


---- Reported by spouliot@videotron.ca 2004-02-06 10:31:50 MST ----

Description of Problem:
We do not report CS0652 warnings (Comparison to integral constant is useless)

Steps to reproduce the problem:
1. Compile the attached sample with MCS. No error/warning are reported.
2. Compile the attached sample with CSC. CS0652 is reported.


Actual Results (with MCS):
# mcs cs0652.cs
Compilation succeeded

Expected Results:
> csc cs0652.cs
cs0652.cs(8,7): warning CS0652: Comparison to integral constant is useless;
the constant is outside the range of type 'byte'

How often does this happen? 
Always

Additional Information:
CSC knows it's useless but doesn't eliminate the condition from the IL
generated (even with optimization turned on). Don't know for the JIT.



---- Additional Comments From spouliot@videotron.ca 2004-02-06 10:32:36 MST ----

Created an attachment (id=165581)
CS0562.cs




---- Additional Comments From miguel@ximian.com 2004-02-07 01:38:30 MST ----

I figured out we should hook this up in Binary.DoResolve, before
calling ResolveOperator, since we have done a cast there to check for
constants already.  

Will think a bit more about this, but its a nice debugging aid. 



---- Additional Comments From atsushi@ximian.com 2005-08-23 15:49:52 MST ----

Created an attachment (id=165582)
proposed fix




---- Additional Comments From miguel@ximian.com 2005-08-23 16:00:13 MST ----

approved, please apply



---- Additional Comments From atsushi@ximian.com 2005-08-23 16:48:25 MST ----

I checked in this "a bit modified" patch as r48761.

Actually value range check should be done for negative ranges. Thus
the actual comparison became as below:

return type == TypeManager.sbyte_type && (value >= 0x80 || value <
-0x80) ||
	type == TypeManager.byte_type && value >= 0x100 ||
	type == TypeManager.short_type && (value >= 0x8000 || value < -0x8000) ||
	type == TypeManager.ushort_type && value >= 0x10000 ||
	type == TypeManager.int32_type && (value >= 0x80000000 || value <
-0x80000000) ||
	type == TypeManager.uint32_type && value >= 0x100000000;


Imported an attachment (id=165581)
Imported an attachment (id=165582)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>tested on both RH9 and WinXP</cf_op_sys_details>