> 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. ************************************************************************* _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
