views:

138

answers:

4

Hello!

I have the following question:

Does Microsoft Visual Studio (I'm using 2008 SP1) offer any way to override standart C functions such as malloc, memcpy?

Suppose I have some externally built library, which contains malloc.obj and memcpy.obj. Library is called library.lib.

How should I build my project so that the compiler uses my (overriden) versions of malloc() and memcpy() routines instead of those provided (I assume they share the same syntax)?

The point of whole this thing is about changing every malloc in my project without making name aliases like my_malloc or similiar, so that I could compare performance.

Is this possible?

Thank you.

+1  A: 

Have not tried this but - in Project properties -> Linker -> Input, set 'Ignore All Default Libraries' to Yes. Then set 'Additional Dependencies' = library.lib;libcmt.lib.

This ought to include your library ahead of the standard static CRT. Provided function linkage is the same in each this should do what you want. Though how malloc/free are linked to the OS in the two static libs may be problematic. I assume library.lib also redefines realloc/free/calloc etc?

Steve Townsend
+9  A: 

Is it possible to change the build and link process so that you replace the implementation of memcpy and malloc? Yes. Is it a good idea? Not really.

You'd be better off just using #define logic to rename those functions to something like memcpy_testing and malloc_testing, and then have a single #define that switches between the two. That way your solution is more portable to other build systems, and it's more immediately clear to other programmers what on earth you're doing.

Edit: In keeping with the comments, here is a sample of what you'd do in a shared header file:

#ifdef testing
#    define my_malloc(n) testing_malloc(n)
#else
#    define my_malloc(n) malloc(n)
#endif

You could even support run-time switching if need be by using function pointers:

void *(__cdecl *my_malloc)(size_t);
// ...
void SetToTest() { my_malloc = testing_malloc; }
void SetToStandard() { my_malloc = malloc; }
Reinderien
I don't agree that `#define malloc(n) my_malloc(n)` would be more immediately clear. Actually doing the search/replace in the code itself would be clearer. Replacing with `#define` could even be dangerous: for example, looking at a code site, it would be hard to tell whether it's calling the system implementation or your own, and therefore it'd be hard to tell which deallocator to use. This is even more problematic if linking against code that still uses the system `malloc` (or if some part of the project neglects to use the `#define`).
jamesdlin
I think my idea of renaming and yours are opposite: I propose to write `my_malloc` in the code itself to make it unambiguously clear that something strange is afoot, and in the header write something like `#ifdef testing` / `#define my_malloc(n) testing_malloc(n)` / `#else` / `#define my_malloc(n) malloc(n)` / `#endif`.
Reinderien
Ah, okay. Yes, I agree that that's better. (I interpreted "those functions" to mean "`memcpy` and `malloc`", not the custom implementations.)
jamesdlin
+1  A: 

You can build your own version of the Visual C++ C runtime library (CRT) which contains memcpy and malloc functions (among others) from the source code that can be usually found in \Program Files\Microsoft Visual Studio 9.0\VC\crt. Then link your program with custom CRT.

Alternatively you can use technique from this official article to hook allocation functions.

Kirill V. Lyadvinsky
A: 

Looking at implementation of NedMalloc which is a custom allocator NedMalloc it appears he just uses #define nedmalloc malloc

The header file says it should work on windows.

There's also hoard at hoard it's open source so you can have a look how they do it.

There's a problem for C++ as well. If windows includes define new operator as just using malloc underneath then everything works with your custom allocator. Otherwise you have to override like 6 operators for allocating and deleting things C++ way.

Budric