I would strongly suggest not to #undef such #defines coming from the standard headers; the results may be unpredictable.
Maybe the compiler optimization and inlining strategies relies exactly on such #defines, that is: strlen needs to be __strlen, so that the compiler can recognize it and do the optimizations on it that it is supposed to do ??? Kind regards Bernd Am 23.02.2014 16:55, schrieb John McKown:
Hum, your results are what I was expecting. Perhaps I missed something in my compile parameters. Did you compile using JCL? I am using the UNIX "xlc" command from a UNIX prompt. I don't know why that would make a difference. Would you mind showing me your compile parameters? What version of z/OS are you running on? My compile came from a z/OS 1.13 system. I don't know the maintenance level. I forgot to remove the #undef line. Without the #undef, you get the "builtin" code you saw (with the SRST). I then wondered that perhaps if I forced an actual CALL to the strlen() subroutine, the compiler would "smarten up" and save the result. In both case, with & without the #undef, the compiler did not "save" the results as I had hoped. What the #undef does is force the compiler to use the strlen() function call instead of the builtin. In the <string.h> include, there is a line like: #define strlen __strlen
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
