RE: Bug report: sort.c or AIX compiler

[Lemley James - jlemle]

> IBM's test case is fine, but it's not related to the bug.  The
> bug, as I understand it, is exhibited when you use bool.  IBM's
> test case does not involve bool.

Well, no.  I've discovered that bool isn't really involved; it's an
unsigned problem when dealing with 64-bit math.   The fact that we call
it _Bool is a red herring.  _Bool seems to be fine for what it is. 

The flaw shows itself in sort.c because _Bool on IBM's C compiler is an
unsigned character, and in the code, it is being used to compute an
offset of -1.  When the conversion to 64-bit pointer takes place, by
default the IBM compiler doesn't extend the sign bit of -1 and ends up
way out in space.  

This will happen any time an unsigned data type less than 64 bits (like,
but not limited to, _Bool) is used to compute a pointer offset of -1.  

IBM insists that this is by design and if we want to avoid it, either
use "xlc" or "cc -qnoupconv", which causes the compiler to behave
correctly.

Here is the output on AIX, without and with the option that IBM insists
that I use as a workaround: 

# cc test.c -o test
# ./test
b is true, which is 1 (should be 1)
d is ffffffffffff649
-2 + b is -1 (should be -1)
&d[-1] is ffffffffffff648
&c[4] is ffffffffffff648
&d[-2 + b] is 10000000fffff648
&d[-2 + b] != &c[4] (wrong)

# cc -qnoupconv test.c -o test
# ./test
b is true, which is 1 (should be 1)
d is ffffffffffff659
-2 + b is -1 (should be -1)
&d[-1] is ffffffffffff658
&c[4] is ffffffffffff658
&d[-2 + b] is ffffffffffff658
&d[-2 + b] == &c[4] (OK)

Finally, here's the communication from IBM when I was very blunt about
stating that this is a default compiler problem: 

--- begin IBM note --- 
Hi James, 

There is nothing to fix in cc.  This compiler invocation is intended to
use an older language level, which uses -qupconv.  If using cc, a
developer should be familiar with its uses and the way in which it
works.  This is all documented in the compiler documentation.  The
source code being compiled with cc is written with the assumption that a
newer language level will be used to compile. 

The answer is to use an appropriate compiler invocation, such as xlc, or
else use cc -qupconv.  The compiler invocation cc will not be altered
because it is behaving according to the language level that it conforms
to. 

--- end IBM note -- 

So there you have it.  They are aware of the behavior and have no intent
to fix it.  They claim it is up to the developer to read about every cc
quirk on their platform and work around it. 


*************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be
legally privileged.

If the reader of this message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank you.
*************************************************************************