On 3/31/2014 4:02 PM, Bernd Oppolzer wrote:
We discussed this further with some co-workers on my customers site.
There are some more aspects of this discussion:
a) the C language manual at one certain point states what are pointers
acceptable
to C and what are not. From the wording there it sounds as if pointers
that come
from parameters from other languages (not C) were not acceptable to C -
only
addresses resulting from parameters from other C functions !!! If this
is true ...
how do I do inter-language calls between PL/1 and C successfully?
Ahem.
http://www.trainersfriend.com/Language_Environment_courses/m520descr.htm
-Steve Comstock
b) we are somehow concerned about parameter addresses having the
high order bit on ... we regularly put the high order bit on on all
parameter lists
built by our PL/1 routines for the last parameter (we have ASSEMBLER
interface
modules between the PL/1 and C routines) ... so it is common for the C
routines
to get parameter addresses with the high bit on from PL/1 callers.
c) in some of our C modules, we have logic to CLEAN some parameter
addresses
to 31 bit values - this was because of problems we had with 0C8 abends
in the past.
The logic looks like this:
#ifdef HOST
#define CLEAN_PTR(x) ((void *)((unsigned int )(x) & 0x7fffffff))
#else
#define CLEAN_PTR(x) (x)
#endif
(#define HOST is present, when compiling on the mainframe)
we now are concerned that the logic will be probably thrown away by the
optimizer, if we recompile those modules ... if CLEAN_PTR is applied
to a ptr and the ptr is supposed to be always 31 bit, the bit operation
does make no sense at all. But: this worked for us in the past.
Maybe the whole problem could be solved easily if the compiler did not
throw away logic due to optimization considerations in certain special
cases;
for example: if there are typecasts of pointers to unsigned int involved.
Such a solution would be really helpful and also solve my original problem.
Kind regards
Bernd
Am 31.03.2014 20:27, schrieb Charles Mills:
Well, I think I indicated that my PL/I knowledge was minimal. I was
trying
to illustrate a concept, not write a tutorial on PL/I syntax. From your
response, I would guess I was eminently successful at my intended task. I
guess it's the nature of IBM-MAIN: the more irrelevant the nit, the
greater
the likelihood of a thorough and tedious correction.
I did miss or forget that the idea of his C routine was to go into his C
library routines and "correct" PL/I NULLs; it was not intended to be
called
from "recompoiled" PL/I so as to provide an appropriate form of nulls to
various library routines. I withdraw the suggestion.
Charles
----------------------------------------------------------------------
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
