Perhaps turn off optimization and see what the "raw" compiler produces? That may provide a hint to a solution, or it may just leave the function to do what you want and you will have accomplished your task.
BTW, why a "static" function? Could that be affecting the way the compiler optimization treats the code? HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Thursday, March 27, 2014 11:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Compiler error in z/OS C compiler Hello mainframe C users, today I observed an error in the C compiler, which made me think again about the optimization strategy of the z/OS C compiler. I wrote a small C function; the purpose was to translate pointer values coming from PL/1 modules from NULL() values - PL/1 builtin NULL() yields 0xFF000000 - to "real" NULLs - 0x00000000 - or PL/1 SYSNULL. This is what I did: /**********************************************************/ /* */ /* PLI/1 NULL () => SYSNULL () */ /* */ /**********************************************************/ static void *pli_null_to_sysnull (void *ptr) { unsigned int ppli = (unsigned int) ptr; #ifdef COMPERR printf ("Ausgabe in pli_null_to_sysnull " "wg. Comp-Fehler: %x\n", ppli); #endif if (ppli == 0xff000000u) { return NULL; } else { return ptr; } } the caller then did something like ptr = pli_null_to sysnull (ptr); now: if the printf inside the function was there (that is, COMPERR was #defined), all went OK; the ptr was translated as desired. but: if the printf was not there (no #define for COMPERR), the function was completely thrown away by the optimizer, and the ptr remained unchanged. That looks as if the compiler guessed that the condition (ppli == 0xff000000u) can never be true. But because ppli is an unsigned int, and int has size 32, of course it can (and it does, as we can see in the case when printf is present). What happens here? I believe that the compiler THINKS that because the value of ppli comes from a casted pointer and pointers have 31 bits in z/OS, the value of ppli can never have the high order bit on. But that's just plain wrong, as we see here, if the pointer comes from a PL/1 module, for example, and contains NULL(). That's just the case that I want to deal with, here. We had such problems before, when, for example, pointers coming from outside into C modules had the high order bit on, and the C runtime got into serious troubles with this. Is this a variant of that same old story? What do you think? I found a workaround in the meantime, and I asked our compiler people to send the problem to IBM. But I would like to hear some opinions from the list, too: do you consider the function valid in the z/OS context or not? After all, I expect C to help me even in the systems programming business; I would be very disappointed if for such easy tasks already I had to use ASSEMBLER subprograms. Kind regards Bernd -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
