RE: Redefining a DS

["Dennis Lovelady" <iseries@xxxxxxxxxxxx>]

> I thought memcpy is a C function - there is no implicit connection to
> anything on the i. How it's implemented depends on whatever version of
> C/C++ you use. If it has been a direct mapping to some MI function -
> well, we can't depend on that, cuz implementation changes as better
> ways
> are found. And I'd be very surprised to be able to depend on this

Ummm... it is my understanding (perhaps flawed?  Barbara?  Simon?  Bueller?)
that "procedures" like _memcpy are actually interfaces to the MI
instruction.

I would suggest that the MI memcpy operation code  (and yes, there is one -
see
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/tstudio/tech_ref/mi/MEMCPY
.htm) similarity to the C function is an engineered "coincidence."

I would also suggest that since IBM have opted to provide such interfaces
into the lower levels of the system, they won't take those interfaces away.
Finally, I see occasional suggestion from Barbara and others to use the MI
built-ins (see http://archive.midrange.com/rpg400-l//200301/msg00433.html as
an example), so I say that with some confidence.

As Simon tried to point out, the MEMCPY.htm link I provided above warns
about overlapping fields and undefined results, so I won't be trying the MI
after all.

But I still would like to know why Simon said that about it being more
likely the compiler than the MI.  Is _memcpy() an interface to MI, and does
the ILE RPG compiler influence its actions?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I'm one of those mayors whose management style is to allow free and
unlimited debate up to a point."
        -- Washington, D.C. mayor Marion Barry