Re: Playing with pointers, use of realloc questions.

On 8/12/2015 8:42 AM, Wilson, Jonathan wrote:

...
But, the caller is the one setting up the "Data" to be returned and as
such I have no control over if this field is long enough, even if I were
to have extra parameters with say the length of the "Data" there is
nothing stopping the caller lying and, as far as I know, there is no
programmable way of finding out the definition (or at least its length)
of the field in the caller that was actually passed.
...
Now to prevent the called service program from corrupting memory, I was
wondering if the use of the %realloc would be sensible way of guarding
against overwriting memory, in the called procedure I always perform a
realloc to set up the data to the desired length prior to setting up the
data. Something along the lines of...

I guess I'm a bit late to this thread...

There are (at least) two problems with using %realloc for this.
- If the caller did not use %ALLOC for the parameter, this will not work at all.
- If the caller used %ALLOC, then they have a pointer to the storage, and when you use %REALLOC, the caller's pointer will become invalid. If they try to use the allocated storage they will either get incorrect results or, much worse, they will cause storage corruption.

I would use different procedures as others have suggested, and avoid using pointers at all.

If it's necessary to do storage allocations for some reason, the safest thing is to control them all yourself, and not let your callers access the allocated storage. Instead, just pass back the data they need.

I agree with others that callers should call your procedures correctly, but I think you're right to worry about the possibility of being called incorrectly. Programmers do make mistakes, and the penalty (storage corruption) for passing the wrong parameters may be too harsh for the crime (say copying one call to your procedure and not fixing up all the parameters).