We may have identified a compiler bug specific to the Intel v12 compiler.
What is the complete version number of the compiler that you used for which "FAIL" was printed out?
>>to signed int may overflow, and in C99, this overflow behavior is undefined;
Could you imaging a case like:
somearray[ ( int )-128 ] = -128;
Even if a C/C++compiler could compile it, possibly with some warning, it is the example of out of bound
access and anAccess Violation exception could happen. But, it could also work if there is an another
array located in memorybefore somearray[xxx].
I'm not suprised that problems related to acast'unsigned int' ->'int' are "alive". I hadsimilar
problems with Watcom C/C++ compiler v7.xmany years agoand withMinGW v3.4.2about two
Eventually itwill cause an Access Violation in an application. Take a look at two screenshots below.
By the way, MinGW v3.4.2 gives a warning on that line of code ( on a 32-bit platform ):
if( mt == 2567483614 )
"Warning: This decimal constant is unsigned only in ISO C90"
Note:'2567483614' is greater than '2147483648' ( 2^31 ).
Sure, you can have a negative array index that causes a pointer to get dereferenced out of bounds. But you can also have a negative array index into legit memory because you know what you're doing in memory. C99 standard explicitly allows negative array indices... (they must be "integral" types, signed or unsigned).
In any case, what I am interested in here is why the compiler is apparently erroneously casting a large positive signed value to unsigned (which can create a negative number) before the binary "and" operation that is supposed to convert the index to 0/1. And it seems to be very version specific when it comes to Intel compiler. I'll see if I can chase this down with their support.
>>...Sure, you can have a negative array index that causes a pointer to get dereferenced out of bounds. But
>>you can also have a negative array index into legit memory because you know what you're doing in
Exactly! This is some kind of "hacking technique".
>>...why the compiler is apparently erroneously casting a large positive signed value to unsigned (which can
>>create a negative number)... I'll see if I can chase this down with their support...
I'm afraid that we still don't hear anything from Intel's software engineers. I thinkyou need to
provide two fragments of assembler codes from different versions ofIntelC/C++ compiler to prove
the statementa "possible bug".
Using negative array indices is not hacking.
For example, if you have:
Then p is always pointing to the array start and accessing p[-5] will give access violation.
But if you have:
char *pp = &p;
pp[-5] = 'X';
Is perfectly valid code.
In other words, you need to remember that array pointer does not always have to point at the beginning of an array.
I tested the code with Intel Compiler 12.1.1.062 Build 20111011 (Windows), and regardless of optimization options I always get "correct" as an answer. To compile on Windows I had to remove #include