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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
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
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.htmlReceived on 2022-07-13