I have no idea why this hasn't been noticed until now, I only noticed it by
chance because of one of the projects I'm working on, but a large portion of
the function callback types in etc.c.curl are not declared to use the C calling
convention, instead they are defaulting to the D calling convention.
Let's take curl_global_init_mem for example, it's declared as this:
extern (C) {
CURLcode curl_global_init_mem(c_long flags, curl_malloc_callback m,
curl_free_callback f, curl_realloc_callback r, curl_strdup_callback s,
curl_calloc_callback c);
}
And the callback types referenced are declared as:
/**
* The following typedef's are signatures of malloc, free, realloc, strdup and
* calloc respectively. Function pointers of these types can be passed to the
* curl_global_init_mem() function to set user defined memory management
* callback routines.
*/
alias void * function(size_t size)curl_malloc_callback;
/// ditto
alias void function(void *ptr)curl_free_callback;
/// ditto
alias void * function(void *ptr, size_t size)curl_realloc_callback;
/// ditto
alias char * function(char *str)curl_strdup_callback;
/// ditto
alias void * function(size_t nmemb, size_t size)curl_calloc_callback;
Notice something? They aren't marked as extern(C), nor does the mangled type of
curl_global_init_mem reference them as extern(C) function pointers, instead it
refers to them as extern(D) function pointers.
I'm pretty sure however that malloc, free, realloc, strdup, and calloc don't
take their first parameter in EAX in either the Digital Mars C runtime, or the
Microsoft C runtime, nor even glibc. Although to be fair, they might in Intel's
C library if you have the register call calling convention enabled.
Comment #1 by robert.schadek — 2024-12-01T16:22:15Z