Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 337802 - [1.7][compiler] Usage of 0x0ffffffff is being reported as out of range.
Summary: [1.7][compiler] Usage of 0x0ffffffff is being reported as out of range.
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.7.1   Edit
Assignee: Satyam Kandula CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-22 05:06 EST by Satyam Kandula CLA
Modified: 2011-08-05 02:54 EDT (History)
3 users (show)

See Also:

Attachments
Patch under consideration (5.03 KB, patch)
2011-02-22 09:50 EST, Satyam Kandula CLA 		no flags Details | Diff
Proposed fix + regression tests (7.79 KB, patch)
2011-02-22 10:25 EST, Olivier Thomann CLA 		no flags Details | Diff
Proposed fix + regression tests (9.23 KB, patch)
2011-02-22 10:46 EST, Olivier Thomann CLA 		no flags Details | Diff
Proposed fix + regression tests (9.27 KB, patch)
2011-02-22 11:18 EST, Olivier Thomann CLA 		no flags Details | Diff
Cleanup fix (9.38 KB, patch)
2011-02-22 11:33 EST, Olivier Thomann CLA 		no flags Details | Diff
Show Obsolete (4) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Satyam Kandula CLA 2011-02-22 05:06:05 EST 
int a = 0x0FFFFFFFF;
On using the above line, the compiler built on BETA_JAVA7 reports "
The literal 0x0FFFFFFFF of type int is out of range". 
Note that there are only 8F's and hence it should be a valid integer except they are some leading 0's. 
FYI, JDT/Core source code fails with this error when built with BETA_JAVA7 compiler. There are couple of references of 0x00000000FFFFFFFF.
Comment 1 Satyam Kandula CLA 2011-02-22 05:07:49 EST 
I know the fix and will take care of this.
Comment 2 Olivier Thomann CLA 2011-02-22 08:27:09 EST 
We need to remove all "0" between "0x" and the first non zero digits.
This value is -1 and we have a special treatment for it.
Comment 3 Satyam Kandula CLA 2011-02-22 09:50:30 EST 
Created attachment 189498 [details]
Patch under consideration
Comment 4 Olivier Thomann CLA 2011-02-22 10:25:18 EST 
Created attachment 189499 [details]
Proposed fix + regression tests

I wonder if we should not "clean" the literal ahead of time. This is a draft. I would need to clean the iteration on "0" inside the compute constant value code.
Let me know what you think.
Comment 5 Olivier Thomann CLA 2011-02-22 10:46:52 EST 
Created attachment 189504 [details]
Proposed fix + regression tests

This would be the cleanup version. It can then take advantage of using predefined constants when computing the value.
Comment 6 Olivier Thomann CLA 2011-02-22 11:18:08 EST 
Created attachment 189509 [details]
Proposed fix + regression tests

I forgot to remove one comment in LongLiteral. We could prevent the string buffer creation by doing a second iteration over the literal when the modified flag is true.
Comment 7 Olivier Thomann CLA 2011-02-22 11:33:39 EST 
Created attachment 189511 [details]
Cleanup fix

This patch only creates the string buffer if either '0' or '_' has to be removed.
Comment 8 Srikanth Sankaran CLA 2011-02-22 23:23:09 EST 
Satyam, for fixes getting released only in a branch,
the plan is to leave the milestone empty for the time
being and to mention in white board contents that
it is "Released in BETA_JAVA7 branch only"
Comment 9 Satyam Kandula CLA 2011-02-23 02:02:55 EST 
Olivier, Your patch in comment 7 looks good and hence I have released it in the BETA_JAVA7 branch. Thank you.
Comment 10 Ayushman Jain CLA 2011-06-29 07:03:20 EDT 
Verified using Eclipse Java 7 Support(Beta) feature patch v20110623-0900.