"The value of ESP was not properly saved across a function call." problem [duplicate]

This question already has answers here: Cl开发者_C百科osed 11 years ago.

Possible Duplicate:

Weird MSC 8.0 error: “The value of ESP was not properly saved across a function call…”

I have an OBJ file for which I don't have any soure code. I have used it in another project without any problems. Now I am trying to use it in another project. Here is the way I declare it:

extern "C" bool FileCompare(char* file1, char* file2);

I use it in a function like this:

void myFunction() {
    //some code
    FileCompare(file1, file2); // file1 and 2 are char arrays
}

Then in my main code I call myFunction:

int main() {
    ... some code
    myFunction()
}

When myFunction returns I get "The value of ESP was not properly saved across a function call." in Visual Studio 2010 debugger. However, I know for a fact that FileCompares (the function in the obj file) does its job. When I comment it out everything works fine. I have used this OBJ file in the past without any problems. Considering I don't have the source of the obj file, is there anything I can do to try to "patch" this problem?

Thank you very much

More details: I suspect that the code uses CALL without RET (its written in assembly).

EDIT: I don't know if what I say makes sense the way things work, but since the function corrupts the esp is there anyway to save it and restore it after the function returns?

---

This is either due to a bug in FileCompare() or mismatched calling conventions between the declaration and implementation of myFunction() and/or FileCompare().

You might be able to fix the problem with an appropriate specifier (like maybe __cdecl) on the prototype for FileCompare(). Or you might need to create an assembly language wrapper for the FileCompare() function that fixes things up (since you say that you no longer have the source for FileCompare()).

Figuring out exactly what's wrong without FileCompare() source might require stepping thorough the assembly in a debugger.

---

I run into a similar problem once when I was compiling one project against old header file that differed from the latest by one missing virtual function.