https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/ab_use_of_the_ansi_c_aliasing_rules?lang=en
> On 27 Mar 2014, at 11:51 pm, Bernd Oppolzer <bernd.oppol...@t-online.de>
> wrote:
>
> 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
>
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
