On 2017-11-16 2:14 PM, Kurt Anderson wrote:

Barbara, one thing I changed from your sample code is making this based on the 'cur' pointer. I just wanted to make sure I was right in doing that (and it wasn't a fluke that it was working for me).
dcl-s gSoapMsg_view char(MAX_ELEM_LEN)
based(gp_soapMsg_cur); // can't be varchar


Kurt, that was a bug in my code. You're right, it has to be based on the 'cur' pointer.

There's another nasty bug in my code. "Nasty", because it might not actually cause a problem until long after it was deployed.

Here's my code for reallocating the pointer. See the line marked BUG.

// Make sure there's room
gSoapMsgNewLen = gSoapMsgLen + %len(value);
if gSoapMsgNewLen > gSoapMsgAllocSize;
// Allocate more storage
BUG gSoapMsgAllocSize += SOAP_INCREMENT;
gp_SoapMsg = %Realloc(gp_SoapMsg : gSoapMsgAllocSize);
// Reposition any pointers within gp_SoapMsg
gp_soapMsg_cur = gp_SoapMsg + gSoapMsgLen;
endif;

It's not sufficient to just add the SOAP_INCREMENT size. The string being added might be longer than that, and appending the new string could cause some other allocation in the heap to get corrupted.

It should be
gSoapMsgAllocSize += %len(value) + SOAP_INCREMENT;

To add enough room for the current string plus some extra room to prevent too many reallocations.


This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2020 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].