×
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.
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.
As an Amazon Associate we earn from qualifying purchases.