[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call to HTTP_PARSE ending in error



Note that the incorrect use of pointers as Scott is pointing out often
results in inconsistent and hard to reproduce errors....

Charles

On Tue, May 22, 2012 at 3:26 PM, Scott Klement <sk@xxxxxxxxxxxxxxxx> wrote:
> Hi Tom,
>
> I just got your message -- thanks for the info.  I haven't had a chance
> to try your code yet, but just glancing at it I saw a big problem.
>
> The problem is in the Incoming subprocedure.  Here's what you have:
>
>           if name = 'GetAllotmentListResult';
>              RtnDataPtr = valuePtrds.valptr-2;
>              RtnDataLen = valuePtrds.vallen;
>           endif;
>
> The problem is that valuePtrDS points to memory that's only valid while
> the Incoming subprocedure is still active.  Once Incoming returns
> control back to HTTPAPI, the memory pointed to by ValuePtrDS will be
> freed up and potentially reused for something else.
>
> But, you are saving that pointer and trying to use it later... Ouch!
> This could cause unpredictable results!  Please treat the data pointed
> to by this data structure as "read only" and "only valid while Incoming
> is running".   If you wish to use the data later, please make your own
> copy of it, rather that referencing the same pointer I gave you at a
> later time.
>
> Also, you are subtracting 2 from the valptr...   How could you possibly
> know what's stored in the two bytes of memory that happen to be before
> the data I'm sending you?!   Why would you try to access them?!
>
> Worst of all, your ReplaceInBlock() procedure is actually _changing_ the
> internal memory structures used by Expat.  I have no idea what that will
> do -- but it certainly is dangerous!
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------