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      dcchapman_at_acm.org
     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