Bernd,

Have you looked at the code generated for:

static void *pli_null_to_sysnull (void *ptr)
//static void *pli_null_to_sysnull (unsigned int ptr)
{
// unsigned int ppli = (unsigned int) ptr;
#ifdef COMPERR
   printf ("Ausgabe in pli_null_to_sysnull "
           "wg. Comp-Fehler: %x\n", ppli);
#endif
// if (ptr == 0xff000000u)
   if (!memcmp(ptr,"\0xff\0x00\0x00",4))
   {
      return NULL;
}
   else
   {
      return (void *)ptr;
   }
}

First, note that my character constant is "\0xff\0x00\0x00". It leaves off
the last \0x00 that you had because, by definition, every C string ends
with a 0\x00. When I did a C99 with -O2 (the UNIX command, since I do my C
work in UNIX, the code for that function was "in lined" as follows
(stripping out some uneeded stuff)

          LR       r0,r13            (my comment: point to start of DSA)
          AHI      r0,H'160'         (my comment: add in offset of somedata
from start of DSA)
+         CLC      somedata(4,r13,160),+CONSTANT_AREA(r1,0)  (my comment:
actually address of somedata)
+         BNE      @1L6
*  //static void *pli_null_to_sysnull (unsigned int ptr)
*  {
*  // unsigned int ppli = (unsigned int) ptr;
*  #ifdef COMPERR
*     printf ("Ausgabe in pli_null_to_sysnull "
*             "wg. Comp-Fehler: %x\n", ppli);
*  #endif
*  // if (ptr == 0xff000000u)
*     if (!memcmp(ptr,"\0xff\0x00\0x00",4))
*     {
*        return NULL;
          LA       r0,0
+@1L6     DS       0H

                           Constant Area
 000130  FF000000 C1A4A287 81828540 89954097    |....Ausgabe in p|
 000140  93896D95 A493936D A3966DA2 A8A295A4    |li_null_to_sysnu|
 000150  939340A6 874B40C3 96949760 C6858893    |ll wg. Comp-Fehl|
 000160  85997A40 6CA7406C A71500               |er: %x %x..     |


It don't get no better than this! However the comments on the CLC are
confusing in that they seem to say that the comparison is for the value of
"somearea" whereas the reality is that it is comparing the address of
somearea, as best as I can tell. If not, there there is a whole 'nother bug!



On Fri, Mar 28, 2014 at 8:39 AM, Bernd Oppolzer
<[email protected]>wrote:

> Peter,
>
> thank you.
>
> I read all this carefully, and the link that Charles Mills provided, too,
> but I still think that things are different here. The situations described
> on that site don't fit exactly to my situation.
>
> The unsigned int in my case is large enough to take the address value
> (32 bits vs 31 bits), so there should be no problem with that. The main
> problem comes from the fact that PL/1 decided long ago in history that
> the BUILTIN function NULL which is a pointer that points nowhere
> is implemented as 0xFF000000 instead of 0x00000000 ... which
> makes some sense, because access to 0xFF000000 (which is
> in fact 0x7F000000) will probably abend 0C4 on read, when
> access to 0x00000000 doesn't.
>
> But anyway: if PL/1 callers pass a structure containing pointers to
> C, and they initialize the structure simply by assigning the empty
> string to it, all pointers will contain NULL(), that is 0xFF000000.
> So the C functions receiving such structures have to cope with this.
>
> That's why I would like to check if a pointer contains 0xFF000000.
>
> It should not be that hard ... just because C thinks that there are
> no pointers having the high order bit on doesn't mean that other languages
> think so, too. After all, C is a language on the mainframe and should
> try to work together with other languages that exist on the mainframe ...
> or is that a too practical point of view?
>
> Let's see ... maybe we get help from IBM on this ... I had a similar
> problem some months ago and got it fixed in the end.
>
> Kind regards
>
> Bernd
>
>
>
>
> Am 28.03.2014 14:05, schrieb Farley, Peter x23353:
>
>> And sorry for the typo, that if statement should have read:
>>
>>      if (ppli == (uintptr_t) 0xff000000u)
>>
>> Not unitptr_t.
>>
>> Peter
>>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:[email protected]] On
>> Behalf Of Farley, Peter x23353
>> Sent: Friday, March 28, 2014 9:01 AM
>> To: [email protected]
>> Subject: Re: Compiler error in z/OS C compiler
>>
>> Bernd,
>>
>> ISTM that the url provided by Charles Mills yesterday evening to the "
>> securecoding.cert.org" site is right on target.  The example on that
>> page about using type uintptr_t would seem to apply exactly to your case.
>>  If I were you I would try the uintptr_t solution using both optimization
>> and no optimization.
>>
>> If I understand that page correctly, you might want to try the code this
>> way:
>>
>> /**********************************************************/
>> /* */
>> /*   PLI/1 NULL () => SYSNULL ()                          */
>> /*        */
>> /**********************************************************/
>>
>> static void *pli2_null_to_sysnull (void *ptr)
>>
>> {
>>      uintptr_t ppli = (uintptr_t) ptr;
>>
>>      if (ppli == (unitptr_t) 0xff000000u)
>>      {
>>         return NULL;
>>      }
>>      else
>>      {
>>         return ptr;
>>      }
>> }
>>
>>
>> HTH
>>
>> Peter
>>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>



-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to