curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Necessity of setting CURLOPT_WRITEFUNCTION with Win32 DLL

From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 13 Jul 2022 11:06:16 +0200

On 7/13/22 01:37, John Scott via curl-library wrote:
> Hi libcurl folks,
Hi John,
>
> The CURLOPT_WRITEDATA man page says
>> If you are using libcurl as a win32 DLL, you MUST use a
>> CURLOPT_WRITEFUNCTION if you set this option or you will experience
>> crashes.
> I was curious to investigate why this happens, what the cause of the
> crashes is. However, with curl 7.84.0 I'm unable to reproduce this
> issue. I've cross-built libcurl using the MinGW-w64 toolchain provided
> by Debian Testing and tested the x86_64 binary under Wine, and it seems
> to work just fine without setting CURLOPT_WRITEFUNCTION. I'm certain
> that my test program is dynamically linked.
>
> Is this documentation up-to-date, and if so (primarily for my
> curiosity's sake) why does the crash happen?

There's an explanation for this in an old PR:
https://github.com/curl/curl/pull/1839#issuecomment-326787637

When you only set CURLOPT_WRITEDATA, you cause libcurl to perform fwrite
calls on a handle opened by YOUR application's runtime library with
LIBCURL's own and both units MAY have been linked with different runtime
libraries.

I presume underlying implementation details of FILE * may be
incompatible between runtime library versions on W$.

In short, applications MAY crash if you do this, hence it's preferable
to provide the fwrite function provided by the runtime library used to
open the file.

If your test program does not crash, both libraries are the same or at
least compatible. But that's Russian roulette !

Patrick

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
Received on 2022-07-13