Should a warning or perhaps even an assertion failure be produced if delete is used to free memory obtained using malloc()?

Question

In C++ using delete to free memory obtained with malloc() doesn't necessarily cause a program to blow up.

Should a warning or perhaps even an assertion failure should be produced if delete is used to free memory obtained using malloc()?

Why did Stroustrup not have this feature on C++?

Answer 1

In C++ using delete to free memory obtained with malloc() doesn't necessarily cause a program to blow up.

No, but it does necessarily result in undefined behavior, which means that anything can happen, including the program blowing up or the program continuing to run in what appears to be a correct manner.

Do you guys think a warning or perhaps even an assertion failure should be produced if delete is used to free memory obtained using malloc()??

No. This is difficult, if not impossible, to check at compile time. Runtime checks are expensive, and in C++, you don't get what you don't pay for.

It might be a useful option to turn on while debugging, but really, the correct answer is just don't mix and match them. I've not once had trouble with this.

Answer 2

delete has a special property that free() does not: it calls destructors, which in turn may call more deletes as that object may have allocated other things on the heap.

That said, new also calls the object's constructor, while malloc() does not. Don't mix these things unless you're absolutely sure you know what you're doing (and if you did, you wouldn't mix these things anyway).

Answer 3

In C++ using delete to free memory obtained with malloc() doesn't necessarily cause a program to blow up.

You should never do that. Although some compiler allocate memory for new using malloc, free() doesn't call destructors. So if you mix "new" with "free" you'll get memory leaks, and a lot of hard to deal with problems. Just forget it. It isn't worth the effort.

Do you guys think a warning or perhaps even an assertion failure should be produced if delete is used to free memory obtained using malloc()??

As far as I know, on MSVC trying to delete() memory allocated with malloc generates debug error (something like "pCrtBlock is not valid", although I don't remember exact message). That is - if project was built with debug crt libraries. Happens because debug new() allocates extra memory for every allocated block and this block doesn't exist in memory allocated with malloc.

Why do you think that Stroustrup did not had this feature on C++?

In my opinion, because a programmer should be allowed to shoot himself in the foot with rocket launcher, if he really wants to do that. delete() isn't even supposed to be compatible with malloc, so adding protection against total stupidity isn't worth the effort of making a feature.

Answer 4

A warning would be nice, but this probably does not happen because C++ was originally built upon C, so a runtime error could not be generated because malloc is valid C.

Its still extremely bad practice to do this, even if your program does not crash...

Answer 5

Personally the undefined behaviour of mixing and matching memory allocations schemes makes it undesirable to even mix them within the same program/library.

There are some static analysis tools that can identify this kind of memory allocation / deallocation imbalance and generate warnings for you. However static analysis is never 100% accurate or fool-proof, as there will always be limitations in the tools ability to track variables and memory locations in the program.

Full disclosure: I work at Red Lizard Software writing the goanna static analysis tool for C/C++ and it is capable of detecting this kind of mismatch in some, not all instances.