×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
midrange.com
