Re: [libmicrohttpd] memory issue in MHD_create_response_from_data

[Alexander Antimonov]

Christian Grothoff wrote:
> In general, having two implementations for malloc/free in the same application 
> is a terrible idea.  
Depending of what you call "the same application". If you talk about the 
same binary, than yes, it's terrible, but in such case a linker will not 
be able to build the binary because of a clash of multiple functions 
with the same name, or will just pick up the first of them and will 
build the binary anyway.

If "the same application" is all of the binaries loaded by OS together 
into running process, this is the case when the process (same app) can 
has multiple implementations of any functions and among them malloc and 
free.
It's possible if these functions reside locally in a binary (shared 
object) and not being exported to the global namespace.

As I know, GCC exports all functions in a binary to the global namespace
by default. But I am sure it has options (or function attributes) to 
disable that.
And M$ compiler does not export functions to the global space by 
default, all functions are local. To export some function from a DLL it 
needs to explicitly define this function as being exported by 
"declspec(dllexport)".


> Compiling your C/C++ code with different compilers 
> against different libc's is an equally terrible idea and will likely cause all 
> kinds of problems, not just with MHD.  
I have to tell you such kind of situation is common in the windows world.
An application can use different DLLs provided by different entities and 
built with different C/C++/Pascal/whatever compilers. And almost always 
these DLLs are not available with sources so a developer can build his 
application from sources.
In Free Software world you can take all of the sources you need and 
build them with one compiler. But on windows this is not the case.
By different reasons (political or technical) it's impossible to force 
there entities to use compiler of the developer's choice so that hi/she 
is able to link the application "without problems".

And this mess of binaries happily exists on 90% of the PCs and calls 
each others' functions as long as they use standard ABI an follow the 
rule "do not put your dirty hands into my plate". And that is what I 
suggested in the post before.


> Now, even in that case there is no reason to change the MHD API as you 
> suggested; 
As you wish.

> simply use the other API function to create a response:
>
> struct MHD_Response *MHD_create_response_from_callback (uint64_t size,
>                                                         size_t block_size,
>                                                         
> MHD_ContentReaderCallback
>                                                         crc, void *crc_cls,
>                                                         
> MHD_ContentReaderFreeCallback
>                                                         crfc);
>
> there you already have your "free" callback where you can do as you please.
OK.

> MHD_create_response_from_data is supposed to be the simple method for the 
> simple case of responses that are small enough to fit into memory and that are 
> either on the stack, in an immutable global or malloc'ed (where the malloc 
> must match the malloc that MHD would be using).  If that's not the case, the 
> other way to create a response object should do just fine.
I see your point.

> Best,
>
> Christian