On 1/04/2014 9:37, Bernd Oppolzer wrote:
How do you solve the problem that a pointer coming from a PL/1 module (or ASSEMBLER) and possibly having the high order bit on is not accepted from the C module as a valid pointer and that the results, if you use this pointer, are "unpredictable" or "undefined", as stated by the C manuals? And: if you try to clean the first bit of this pointer by casting it to an unsigned int and switching the bit off, then you get this logic removed from the object code by the optimizer, because the optimizer (of the C compiler) THINKS that a C pointer never has the high order bit set, so there is no need to execute this logic?
Perhaps the answer is to make the parameter an unsigned int, and avoid telling C it is a pointer until you have verified that it is indeed a valid pointer i.e. the routine takes an unsigned int and returns a C pointer.
Of course, you might run into the same problem if the function is inlined into code that has already defined it as a pointer. When receiving these pointers from PL/1, are the received parameters required to be defined as pointers? Can you generally receive them as unsigned int, and use your routine to turn unsigned int into C pointers?
Of course, if there is a calling convention for calling C from PL/1 that handles pointers automatically, that would be preferable.
Regards Andrew Rowley -- and...@blackhillsoftware.com +61 413 302 386 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
