An explanation, which is just a little more paranoid:
if you #undef strlen, the compiler cannot be sure, if "your" strlen
is not quite another function, which does not give the same result
on two subsequent calls ... ???
-------- Original-Nachricht --------
Betreff: Re: Curious observation: lack of a simple optimization in a C
program
Datum: Sun, 23 Feb 2014 19:48:44 +0100
Von: Bernd Oppolzer <[email protected]>
An: IBM Mainframe Discussion List <[email protected]>
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
