On 9/15/2015 1:40 PM, Daniel Stenberg wrote:
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!
To control what version of various libraries I am using in my
application, I don't use DLLs (or .so files) and so I don't have direct
experience with the problem at hand. However, your description led me
to the following Microsoft Developer Network page, and I suspect it is
the source of the DLL warning:
https://msdn.microsoft.com/en-us/library/ms235460.aspx
It says CRT (C runtime) objects are valid only for the copy of the CRT
library where they are allocated or set. If the DLL uses a different
copy of the CRT library than the application, then (for example) a file
handle from the application cannot be used within the DLL. This can
cause crashes if the application links to a DLL that was built elsewhere
or at a different time.
This strongly suggests that if libcurl is linked to the application as a
Win32 or Win64 DLL, cURL user code must provide a callback function -
even if the only purpose of the callback is to call fwrite(). Can
someone with more Windows DLL experience confirm this? That will help
with clarification of the CURLOPT_WRITEFUNCTION and CURLOPT_WRITEDATA
wording.
--
David Chapman [email protected]
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
