No, finally no, because I used stdcall by default in my apps and have no
problem using libcurl.

The problem isn't redefine the __cdecl calls in libcurl, the problem is you
need to know how tu use the module.

If you think on that you had said, you will modify more open source projects
call convention definitions than only use some lines of code before the
#include preprocesor directive.

The philosofy is you adapt your sources for they use a standard module, no
the modules will be adapted for the use into your apps.

Good luck.

CL writes:

> Thanks for the feedback. That certainly led me back on track again.
> In addition to adding __cdecl to the callback function, I also
> explictly placed __cdecl on all functions that I called in
> <libCurl.h>. Considering that libCurl always uses __cdecl calling
> convention, should this change be included in the latest CVS version
> so that others building Win32 applications with __stdcall doesn't run
> into the same problem?
>
> Calu
>
>
>
> On Thu, 24 Feb 2005 08:07:52 -0800 (PST), Jeff Phillips <jeff_at_jeffp.net> wrote:
>> Hello CL,
>>
>> I don't recommending building libcurl with the stdcall
>> convention, because you won't be able to invoke
>> libcurl's vararg functions (like dfprintf_format and
>> curl_formadd) if you do this.
>>
>> That said, when you rebuild libcurl as cdecl, the
>> trick will be to ensure that the various libcurl
>> callbacks in your application are declared as cdecl
>> rather than stdcall, because libcurl, when compiled as
>> cdecl, will expect to clean the stack after invoking a
>> callback. So here's an example:
>>
>> size_t __cdecl write_function(char* szptr,
>> size_t sz, size_t nmemb, void* pvData)
>> {
>> return sz * nmemb; // for now
>> }
>>
>> Set up this callback with:
>>
>> curl_easy_setopt(easy, CURLOPT_WRITEFUNCTION,
>> write_function);
>>
>> Hope this helps,
>> Jeff
>>
>> --- CL <jscript_at_gmail.com> wrote:
>>
>> > I'm trying to add libcurl to an existing windows
>> > application that must
>> > uses stdcall calling convention. I've added /Gz
>> > (stdcall rather than
>> > cdecl ) to CCDEBUG and CCNODBG in makefile.vc6. Most
>> > of the souce code
>> > compiled without warning/errors after adding this
>> > flag. I'm only
>> > getting 4 errors that complains pretty much on the
>> > same problem:
>> >
>> > error C2152: 'function' : pointers to functions with
>> > different attributes
>> > warning C4024: 'dprintf_formatf' : different types
>> > for formal and
>> > actual parameter 2
>> > error C2152: 'function' : pointers to functions with
>> > different attributes
>> > warning C4024: 'dprintf_formatf' : different types
>> > for formal and
>> > actual parameter 2
>> > error C2152: 'function' : pointers to functions with
>> > different attributes
>> > warning C4024: 'dprintf_formatf' : different types
>> > for formal and
>> > actual parameter 2
>> > error C2152: 'function' : pointers to functions with
>> > different attributes
>> > warning C4024: 'dprintf_formatf' : different types
>> > for formal and
>> > actual parameter 2
>> >
>> > I'm pretty new to libcurl, and it took nearly the
>> > whole day yesterday
>> > for me to figure out the 'unresolved external symbol
>> > __imp__curl*'
>> > errors was related to this mix use of calling
>> > conventions. I
>> > appreciate if anyone can point me in the right
>> > direction in either:
>> > 1. how to mix cdecl and stdcall in the same
>> > application
>> > 2. what type of changes do I have to make to fix
>> > those errors listed here
>> >
>> > TIA
>> >
>> > calu
>> >
>>
>>
 

Samuel Díaz Garcí­a
Director Gerente
ArcosCom Wireless, S.L.L.

mailto:samueldg_at_arcoscom.com
http://www.arcoscom.com
móvil: 651 93 72 48
tlfn.: 956 70 13 15
fax: 956 70 34 83
Received on 2005-02-24