Dumb question: why NOT use real C where all those problems go away?
CharlesSent from a mobile; please excuse the brevity. -------- Original message --------From: "Farley, Peter x23353" <[email protected]> Date: 8/16/18 10:33 AM (GMT-06:00) To: [email protected] Subject: Re: Using the Binder API and MetalC Peter, (Good name by the way ... :) It is not important to separate the data from the prototypes, that was just one method to achieve the desired end result - the ability to use the __iew_api.h C language data definitions in a MetalC program where one cannot use the predefined C language API functions or their prototypes. The problem is that in MetalC with the NOLONGNAM<E default those function prototype names result in the compiler trying to generate "duplicate external names" (the first 8 characters of many of the function prototype names are identical). Using option LONGNAME is not an option because that requires GOFF-format output from the assembler and that means that all separately compiled subroutines must also be compiled with LONGNAME and GOFF in the assembler step, and that creates its own set of different problems, like how the heck does one link all of them together and get a successful executable out of it. I plead ignorance of GOFF and the processes to use it successfully, but my education in that area is sorely lacking. Mea culpa. Anyway, in MetalC those predefined C language API functions aren't useable anyway because the executables they define are packaged in a DLL, which I suspect is very difficult to set up to use in MetalC, if it can be done at all. Yes, one could use "#define" to "adjust" the predefined function prototype names so that they are all unique in the first 8 characters, but that seems like a lot of trouble (there are quite a few function names) for a set of routines that will not and cannot (easily) be used in the MetalC environment. So in MetalC it is possible to use the data definitions packaged into __iew_api.h when processing the returned data from the binder API but it is not possible to use any of the predefined function prototypes to access the API itself. However, in MetalC it is quite easy to use the assembler macro IEWBIND to actually invoke the binder API functions, just like an assembler program would do. But rather than use the assembler data definitions, MetalC can use the C language data area definitions from the API header to access the returned binder data. It would be very convenient to have the Binder API header notice that the XLC compiler option METAL is turned on (feature test macro __IBM_METAL_ is DEFINEd) and simply bypass the predefined function prototype definitions entirely, since they are unusable in MetalC anyway. Or any other method which achieves the same end result, I would not want to limit IBM's innovation in solving the problem. As for reasons not to use LE C, as I stated in an earlier reply in this thread I am not in a position to discuss it publicly. I am a little confused by the several questions in this thread which seem to imply that using MetalC instead of LE C for accessing the Binder API is somehow beyond the pale of reasonableness. Would these questions would be asked if the thread was about using assembler to access and use the data from the binder API? If not, why is using MetalC (which after all has been touted as the "smart" assembler replacement for the next generation of programmers) to access and use the binder API data seem to be a problem? Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Peter Relson Sent: Wednesday, August 15, 2018 1:18 PM To: [email protected] Subject: Re: Using the Binder API and MetalC <snip> for future maintainability it sure would be nice if IBM split the /usr/include/__iew_api.h into two parts - Data definitions and function prototypes. </snip> OK, I'll bite. Why is it important to separate the data from the function prototype? Isn't the existing one syntactically correct? It might not be usable in Metal C, but does its presence cause you harm? Could you use #define to "change" the name to something else if you needed a different name? And, out of curiosity, do you have a requirement to avoid an LE runtime for whatever you are doing here? Metal C is intended to solve a problem, it is not intended to let you do everything you can do in C. Perhaps what you really want is, in addition to what is there, a function prototype that would let you provide the target address (e.g., iewxxxx_byaddr). You would have to get that address (such as by LOAD through __asm). That pre-supposes that the target routine actually supports a call using a "standard" parameter list which it sounds like the binder API's do. If an additional function prototype would help, that would be a reasonable thing to ask for. Peter Relson z/OS Core Technology Design -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
