The issue is solved.
With the specification of the writeheader (with headerfunction unset),
when reading headers, the writefunction was used with the writeheader as
userdata, not writedata.
On 1/13/14 3:37 PM, Dan Fandrich wrote:
On Mon, Jan 13, 2014 at 11:21:41AM -0500, Joshua Kordani wrote:
This was originally posted to the curl-users group, and I was encouraged to
post here instead.
http://paste.lisp.org/display/140893
annotation 1 is a single code file listing that should compile, (you just need
to link curl)
annotation 2 is the output I get of running that code on a test rtsp url
I am running on osx 10.7.5 with the latest curl from macports.
I am attempting to use writedata and writefunc to parse a response header from
the server and hand it back out to my application. I've been attempting to
debug this for a few days. It seems to me that the pointer that gets given to
the curl library doesn't make its way to the writefunction. I print out the
value of the pointer before I pass it to curl, and in my test function I print
out the value of the userdata pointer, and they don't agree.
In an effort to clarify, I declare a pointer to a struct, initialize it with
new, and pass it to the curl_writedata function. Some of my printfs aren't
updated to reflect that, earlier in troubleshooting I'd declared a local struct
and passed its address instead. I encountered the same problem.
I have 2 helper macros in there to catch any error as a result of failed calls
to curl_easy* functions. I have a test struct I use to pass data in and out of
the writefunc, but the writefunc is just a stub for now, outlining what I'm
trying to do to access userdata.
Thanks for any assistance with this.
I didn't spot anything obviously out of the ordinary with the way those curl
options were set up. There's a bug while creating url though--strlen() is being
called on an uninitialized array. And there's an edge condition whereby url
could end up being non-NUL terminated. That could cause a heap overflow when
uri is populated, after which all bets are off.
If you still have the problem once fixing that, can you correlate the pointer
value you see printed in the callback with anything else? Could it be equal to
the stdout handle, for example? Can you try paring down the setopt calls even
further & see if it makes any difference?
Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
--
Joshua Kordani
LSA Autonomy
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
