× 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.



Pete:

So, in effect, your program "pulled the rug out from under itself"... *:-o*

The memcpy() and memmove() functions in C, as implemented on OS/400, uses the CPYPWP MI instruction "under the covers" which takes care of copying pointers with their (valid) tags, but (obviously?) this will not adjust pointers to point to new relative positions within a block of storage if you %realloc and move the entire block.

Are you allocating a large block of storage and then sub-allocating nodes within that block, and then decides to %realloc the entire block? If so, do not use %realloc, but rather, just allocate another large chunk (block) and continue sub-allocating nodes from that new block. That way, all of the existing pointers will remain valid, as their original "chunk" (block) will not get moved.

Hope that helps,

Mark S. Waterbury

> On 1/9/2011 12:14 AM, Pete Hall wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-01-08 17:04, Jon Paris wrote:
On Jan 8, 2011, at 1:00 PM,rpg400-l-request@xxxxxxxxxxxx wrote:

There's a gotcha though. If the allocated storage contains pointers, they may no longer be valid after running realloc
Have you had experience of this happening Pete? I was under the impression that the move of the storage was done pointer-safe to avoid this possibility.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com


Yes. I was under that impression too, but at v5.4.0 linked list nodes
ended up containing garbage after running realloc. The system still
considered the pointers valid. At least it didn't complain about them.
They just no longer pointed to the data. I'm assuming they were still
pointing to the original storage, but I really don't know that.

- -- Pete Hall
pete@xxxxxxxxxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0pRDQACgkQXczQcKdXKg7g8wCeIZE62P55ABjUyCQS2NzgNTw5
WzUAnjos1/mDS3OaGt6goEc1hKFmwQnI
=nJXU
-----END PGP SIGNATURE-----

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.