Community
Participate
Working Groups
Created attachment 228453 [details] Please see that checkpoint1 and checkpoint2 are greyed out which shouldn't Hi I've found a problem and I think it might be an eclipse bug. Please see my attachment. I am on redhat 5 x64 running juno. The following code prints out checkpoint2. However, eclipse grayed out checkpoint1 and checkpoint2 . Appraently, eclipse uses a different ULONG_MAX value as from the gcc compiler. Is this a bug from eclipse? #include <stdio.h> #include <limits.h> int main() { printf("%llu\n", (unsigned long long) ULONG_MAX); /* prints 18446744073709551615 and checkpoint2 */ /* but hover mouse over, the ULONG_MAX shows (9223372036854775807L * 2UL + 1UL) */ #if (ULONG_MAX >> 31) == 1 <---- grayed out printf("checkpoint1\n"); #elif (ULONG_MAX >> 63) == 1 <---- grayed out printf("checkpoint2\n"); #else printf("checkpoint3\n"); #endif return 0; }
Is this a bug? Can someone please try it and see if you see the same thing? Thanks
Hi, i guess that the issue is, that the biggest integer Data Type in Java is long, which is a 64 Bit SIGNED type. This example shows that: #include <stdio.h> #include <limits.h> #define TEST_MAX 0x7fffffffffffffffUL int main() { printf("%llu\n", (unsigned long long) TEST_MAX); #if (TEST_MAX >> 31) == 1 printf("checkpoint1\n"); #elif (TEST_MAX >> 62) == 1 printf("checkpoint2\n"); #else printf("checkpoint3\n"); #endif return 0; } CDT should support longer Integer and Unsigned Integers up to 128 Bit.
Hi Klaus Thanks. I don't see an existing bug so I created one last week, ID 403404. I used your example and yes the checkpoint2 is NOT grayed out. My case is not as simple as printing out "checkpoinsts". I actually have some typedef within each if condition. Wrongly grayed out means the typedef declaration within the if statement will NOT be known and so the indexing throughout the whole program fails. Is there a quick fix that we can do to avoid this situation? Thanks David
*** Bug 426741 has been marked as a duplicate of this bug. ***
*** Bug 526414 has been marked as a duplicate of this bug. ***
Now that we use Java 8, we may be able to fix this without having to resort to something like BigInteger for our value representation, since the Long class now provides utilities for treating Long values as 64-bit unsigned integers (see e.g. https://docs.oracle.com/javase/8/docs/api/java/lang/Long.html#compareUnsigned-long-long-).
(In reply to Nathan Ridge from comment #6) > Now that we use Java 8, we may be able to fix this without having to resort > to something like BigInteger for our value representation, since the Long > class now provides utilities for treating Long values as 64-bit unsigned > integers (see e.g. > https://docs.oracle.com/javase/8/docs/api/java/lang/Long. > html#compareUnsigned-long-long-). There are two challenges to implementing a solution along these lines: 1. The way CDT currently implements computations with values, by the time we get into the code that performs the actual computations, the information about the *types* of the values is lost. (In fact, for some codepaths, the types of the values are not resolved to begin with.) Having the types available is important because e.g. using compareUnsigned() would give wrong results if the values were, in fact, signed. So the code would need to be reworked to ensure that the types are always resolved, and propagated to the code that performs the computation. 2. While the Long class provides *some* unsigned operations, such as compareUnsigned, divideUnsigned, and remainderUnsigned, it doesn't provide all operations. For example, for the testcase in comment 0, we would need a "rightShiftUnsigned" operation.
(In reply to Nathan Ridge from comment #7) Right shift unsigned is just >>>, isn't it?
(In reply to Sergey Prigogin from comment #8) > Right shift unsigned is just >>>, isn't it? Looks like it. I just didn't know Java had such an operator :) So I think part #2 from the previous comment can be disregarded. The problematic code examples we've encountered so far just seem to need "compareUnsigned" and ">>>".
*** Bug 559622 has been marked as a duplicate of this bug. ***
Thanks for Nathan to pointing me to the original bug report, shame on me for not finding it in the first place. I came across the issue while parsing large literals. I will try to dig a little deeper into the issue and see if I can at least propose a solutions. Unfortunately I am completely new to the Eclipse world from the viewpoint of a contributor (I am quite used to the pull request-approach-style of GitHub projects) so any tips into directions of contributing guides and so on are welcome.
(In reply to Christian Banse from comment #11) > I came across the issue while parsing large literals. I will try to dig a > little deeper into the issue and see if I can at least propose a solutions. > > Unfortunately I am completely new to the Eclipse world from the viewpoint of > a contributor (I am quite used to the pull request-approach-style of GitHub > projects) so any tips into directions of contributing guides and so on are > welcome. You can find some docs on contributing here: https://wiki.eclipse.org/CDT/contributing The place to start looking in the code would be ValueFactory methods like applyBinaryOperator() and applyUnaryOperator().
