On Sat, 23 Aug 2025 17:30:14 -0500, Jon Perryman <jperr...@pacbell.net> wrote:
>>At optimization levels 0 and 1, it did indeed load 7 into a register and make >>a call to a generic memcpy() routine. > >Expected but if I was doing C on z/OS, it would be disappointing. Optimization >2 gives you MVC which could potentially yield very different results than >calling the generic memcpy(). If this was the only one, then fine but I >suspect this common. Sorry - what is your complaint about IBM C? The generated code has been nothing other than totally beautiful since I first started using it - when it first came out - as a program product - IBM C/370, circa 1988. (before then it was a program offering from Whitesmith I think - which I also briefly used). It generated better assembler than I would write myself - because I wrote assembler for readability, not efficiency. The C compiler could go mad. Regardless - it is the compiler's job to make memcpy behave the same regardless of whether it generates inline code or a function call. Anything else is a bug. Have you raised a bug report on IBM C? I am not aware of any outstanding 35+ year old bug in memcpy. >I suspected this because IBM tends to do things right. Far > more impressive would be if IBM did FOPEN right. IF > you specify RECFM=FB LRECL=80, does it pass a string, > a DCB or separate args. fopen() is dictated by C90. IBM C is also C90-compliant. They have an extension too. It's all documented, and all been working fine for 35+ years too. I have no idea what your complaint might be. This is a fantastic language and a fantastic compiler. And probably the first or close to the first to be fully ANSI C89 compliant. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
