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
