This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In our preprocessor evaluation we have potential problem: #if number1LL + 100 < 0 ... #else ... #endif now any number constant in preprocessor expression is converted into Java type long (which is signed long 64 bits), so the expression above could be correct, but the following could be not: #if number1UL + 100 < 0 ... #else ... #endif the problem is arithmetic overflow
another problem is from bug http://www.netbeans.org/issues/show_bug.cgi?id=79848 The problem occurs when 64-bit integer value appears in preprocessor conditional directive. Java integer data types aren't large enough to store such values. No exception is thrown. The remaining problem is that some conditionals might be evaluated incorrectly and thus incorrect conditional branch would be parsed. The given example from boost works as it should. The example that doesn't work correct is: #if __LONG_LONG_MAX__ < 18446744073709551615 void foo32() { } #else void foo64() { } #endif On 32-bit system, it should contain foo32(). Now code model reports foo64().
Seen this trying to add the openldap "liblmdb" library as a project... The following condition fails the check in the source file mdb.c: #elif (-6 & 5) || CHAR_BIT != 8 || UINT_MAX < 0xffffffff || ULONG_MAX % 0xFFFFUL # error "Two's complement, reasonably sized integer types, please" #endif The error case is the final "ULONG_MAX % 0xFFFFUL" - in the real C preprocessor this works, since a 64 bit value ULONG_MAX evenly divides by 0xFFFF (0x1000100010001 times) and the module is 0. In netbeans, the check fails, since it casts it to a signed long resulting in -1 module 65535, which is -1 and not 0.