0

I am aware of this question and its solution. Its solution (to include two header files listed below) is already in the code, so the post was unhelpful relative to my program.

I am working on an MFC program, using an old version of ZLib, specifically its 2005 version.

To practice with the zipping library, I attempted to use it with a regular C++ console program and it worked successfully (it added files correctly to a zip file).

Now, I am trying to add it in my MFC program. When pressing a button, a function is called and one of its jobs is to add files to a zip file. The thing is, it DOES work, but ONLY when the Run button is pressed, leaving the program to run on its own. The file is compressed successfully in the correct .zip file... HOWEVER, the issue comes from when I add a breakpoint and step through the program in the debugger.

Upon reaching the line: buf = (void*)malloc(size_buf); (found in the CMiniZip::OpenZip(const char* sOutFn) function within minizip.cpp file, if that helps or matters), I come across an error malloc.cpp not found. Strange, as both <stdlib.h> and <malloc.h> are both included as mentioned in the solution of the question linked at the start of this post.

My confusion (and my question) comes from this: why will the program run and compress files as expected when pressing the Run button, but not run when stepping through the program with the help of a breakpoint and the debugger. And why do both these methods work just fine in a non-MFC C++ console program?

Note: The files I zip and the zip folder itself are not touched at all by me while stepping through the program. I am simply clicking the Step Into button with the debugger. AND, this issue did not show up when adding a breakpoint and stepping through the regular C++ (non-MFC) program.

I am using Visual Studio C++ 17 Professional.

Any insight is appreciated, thank you in advance ! :D

Husam Chekfa
  • 77
  • 7
  • 2
    Installing the source code for the Windows Runtime Library may get you further, but you could just step over that line or cancel the dialog and step through the assembly or step out until you hit your code again. The source code is not necessary to compile and run because the runtime is linked as a library, it's already been compiled. You don't need it for debugging either as long as you accept there are some functions you can't step into. – Retired Ninja Jul 22 '22 at 21:38
  • @RetiredNinja ```the source code is not necessary to compile and run because the runtime is linked as a library, it's already been compiled``` so you're saying that my issue should not have any effect now or in the future on the usage of the function or cause errors with the zipping process ? (considering it is zipping correctly) – Husam Chekfa Jul 22 '22 at 21:40
  • No, it's just a debugging thing. If you had another 3rd party library with debug symbols but no source code you'd have the same issue trying to step into the code. You might even have the issue trying to step into some MFC functions, I don't remember if all of the source is available for those or not. You might also try turning on Just My Code so it skips over those functions for you. https://devblogs.microsoft.com/cppblog/announcing-jmc-stepping-in-visual-studio/ – Retired Ninja Jul 22 '22 at 22:11

1 Answers1

-1

Turns out there is no issue at all.

C++ console programs are different from MFC here. Stepping through that line in a console program is the same as stepping OVER that line in MFC.

In MFC, you are actually given the option of seeing the assembly or rather, disassembly, code, by clicking a Disassembly option in the bottom half of the "error" page.

There is not issue. The malloc function is simply hidden.

And it would be better to change that ancient malloc and free to new and delete.

Husam Chekfa
  • 77
  • 7
  • Oh, thank you, dear me for the thoughtful research and effort for finding the answer !!! <3 – Husam Chekfa Jul 22 '22 at 22:28
  • The pleasure is all mine ^^' – Husam Chekfa Jul 22 '22 at 22:28
  • 2
    *"And it would be better to change that ancient `malloc` and `free` to `new` and `delete`."* - That doesn't make sense. The difference isn't about age. `malloc`/`free` are C, `new`/`delete` are C++. And if you ever looked into your `new` implementation, you'll see that it most likely calls `malloc` as part of its operation. If you want to avoid calling `malloc` then `new` isn't part of a solution. – IInspectable Jul 23 '22 at 06:33
  • Ah interesting I will look more into that thank you, I had not considered the C++ implementation would use C's somewhere – Husam Chekfa Jul 24 '22 at 21:53