On Tue, 15 Sep 2015, David Chapman wrote:
If you're using libcurl as a win32 DLL, you MUST use the CURLOPT_WRITEFUNCTION if you set this option or you will experience crashes.
Due to how ownership of that FILE pointer is handled.
I don't think the wording here is at all clear. Are you saying that when cURL is used as a Win32 DLL, fwrite is not a valid CURLOPT_WRITEFUNCTION even if passed in explicitly?
Hm, yes I guess that is the logical conclusion and it is a good question. I'm not sure, maybe our way of using it makes it different? The problem has something to do with the FILE * being owned by the application and it can't pass it on to the DLL to be accessed from there, but the flow isn't 100% clear to me.
Or are you saying that use of NULL as a CURLOPT_WRITEFUNCTION is not valid when cURL is used as a Win32 DLL, and that a pointer to fwrite must be passed in (or else the call should be skipped)?
The regular way we've phrased it, is that you need to implement a write callback. I'm not sure what happens if you just put fopen there.
All this is just info I've gathered and learned from other libcurl users, I am myself not an experienced wanderer in the world of Windows memory setups and concepts.
In either case, the documentation in the CURLOPT_WRITEFUNCTION page should have the same warning. You don't want pages to be inconsistent with each other.
Agreed! -- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
