[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] memory issue in MHD_create_response_from_data

From: Alexander Antimonov
Subject: Re: [libmicrohttpd] memory issue in MHD_create_response_from_data
Date: Sun, 08 Feb 2009 21:08:09 +0200
User-agent: Thunderbird (X11/20080505)

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,
                                                        crc, void *crc_cls,

there you already have your "free" callback where you can do as you please.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]