Behaviour of malloc with delete in C++

Question

int *p=(int * )malloc(sizeof(int));

delete p;

When we allocate memory using malloc then we should release it using free and when we allocate using new in C++ then we should release it using delete.

But if we allocate memory using malloc and then use delete, then there should be some error. But in the above code there's no error or warning coming in C++.

Also if we reverse and allocate using new and release using free, then also there's no error or warning.

Why is it so?

Solution 1

This is undefined behaviour, as there's no way to reliably prove that memory behind the pointer was allocated correctly (i.e. by new for delete or new[] for delete[]). It's your job to ensure things like that don't happen. It's simple when you use right tools, namely smart pointers. Whenever you say delete, you're doing it wrong.

Solution 2

then there should be some error

There is. It is just not necessarily apparent.

The C++ standard (and the C standard, on which the C++ standard is modeled) call this kind of error undefined behavior. By undefined they mean that anything at all may happen. The program may continue normally, it may crash immediately, it may produce a well-defined error message and exit gracefully, it may start exhibiting random errors at some time after the actual undefined behavior event, or invoke nasal demons.

It is your responsibility to watch out and eliminate these errors. Nothing is guaranteed to alert you when they happen.

Solution 3

Use free() not delete.

if you malloc you then have to call free to free memory.

if you new you have to call delete to free memory.

Here is a link that explains it.

Comments

[Kuba hasn't forgotten Monica]

Basically, the C++ standard says that if you allocate with malloc and free with delete, you can launch a nuclear strike. You wouldn't want that do happen, would you, now? Well, let's be realistic: if you insist on doing it, you'll pay for it months or years later, 3 days before you're due to go for a family vacation, and you'll spend 48h straight figuring out the problem. That's what undefined behavior means in practice. Sleepless nights.

[Emily L.]

I agree that this is UB, but I would like a standard reference to where it says so please :)

[n. m.]

@EmilyL: the C++ standard does not specifically address mixing new and free. It says you may only pass to delete what you've got from new. The C standard says likewise about malloc and free.

[Kyle Strand]

Whoa whoa whoa, I was with you until your last sentence, and I like smart pointers. They're not always an appropriate substitute for new/delete, though (for instance, what if you're writing your own smart pointer class, and you're deploying to an embedded machine with no standard library? What if you're stuck with an old compiler that only provides auto_ptr as a smart pointer?), so it's needlessly limiting to say that using delete is "doing it wrong" (even if it's true that smart pointers are usually a better approach).

[Puppy]

Actually, that still is doing it wrong. You shouldn't delete directly in your smart pointer, you should instead take a function object (either as template or type erased) and use that to delete the object. The only one single delete required in adding smart pointers is in std::default_deleter.

[Cat Plus Plus]

@KyleStrand Ugh those dumb arguments crop up again and again. If you're writing your own smart pointer class or writing embedded software you're not wondering whether you can mix malloc and delete. Wrong audience. Besides the amount of cases where you'd write your own smart pointer is close to 0, because unique_ptr is generic enough for almost everything (and those other cases are either shared_ptr or deep-cloning value_ptr and all of that is written already anyway). And if you're stuck with 5+ year old compiler then someone's doing it wrong for sure (also Boost).

[Kyle Strand]

@CatPlusPlus In that case, it sounds like what you really meant was "when beginners use delete, they're doing it wrong"--which is arguably true, but what you said was much broader than that. As for 5+ year old compilers, I work for a company that is currently in post-release support for several embedded systems that were programmed using MSVC 2008 (and in one case 2003) targeting XP Embedded and Windows Embedded Standard 2009, and they simply do not have the manpower to port the codebase forward as part of their ongoing maintenance efforts, nor is there any urgent reason to do so.