problem of providing my own version of malloc/free

Discussion in 'Windows Vista Drivers' started by ronghuazhang, Oct 10, 2005.

  1. ronghuazhang

    ronghuazhang Guest

    Due to some reason, I have to provide my own malloc/free/calloc
    functions so that other parts of the driver are happy. These functions
    are simply a wrapper around ExAllocatePool. However, when I compile it,
    the linker complains: "warning LNK4217: locally defined symbol _free
    imported in function xxxx".

    This is the free() function:
    void __cdecl free(void *p)

    How can I get rid of this message? Thanks
    ronghuazhang, Oct 10, 2005
    1. Advertisements

  2. ronghuazhang

    Skywing Guest

    You (or the header you are including) is using __declspec(dllimport) in the
    prototype for free - remove that decoration and link.exe will be happy.
    Skywing, Oct 10, 2005
    1. Advertisements

  3. ronghuazhang

    Demetrius Guest

    void __cdecl operator free
    Demetrius, Oct 11, 2005
  4. ronghuazhang

    ronghuazhang Guest

    Thanks for the reply. My case is a little complicated.

    The driver is compiled with another .c file, which includes stdlib.h
    and calls malloc/free. This .c file is shared by other parts of my
    project. It's also used by some user level applications. So changing it
    to remove the 'stdlib.h' inclusion is not an option (according to your
    reply, I think this header file is the cause for the warning). Is there
    other ways to get around this issue? Thanks again
    ronghuazhang, Oct 11, 2005
  5. ronghuazhang

    Skywing Guest

    How about making it conditional based on some compiler option?


    /* do one thing */


    /* do another thing*/



    You might consider just renaming your malloc/free calls entirely based on
    that conditional. For instance have a "my_malloc" and "my_free", which
    would be #define'd to malloc/free or something else in kmode, to avoid the
    linkage warning.
    Skywing, Oct 11, 2005
  6. If a person needs to build 2 different ways, one approach is to split the
    builds into 2 pieces, with a sources file for each, and each sources file
    with appropriate include paths and other directives. This approach works
    even when the builds are for a single driver: Build one piece as a .lib file
    (eg, TARGETTYPE=DRIVER_LIBRARY) and have the other piece include that file
    when the second piece is built.

    James Antognini
    Windows DDK and WDK Support

    This posting is provided "AS IS" with no warranties, and confers no rights.
    James Antognini [MSFT], Oct 12, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.