Sign in to follow this  

new/malloc incompatability?

This topic is 4198 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Before I get to my problem let me start off by clearing things up so I dont get a ton of "malloc sux, use new!" I am extending a C++ program to add some more functionality. This program uses functions supplied by a library written in C. Also before I continue, this is being developed on VC++ 5.0 (I know, I know...I dont have a choice in the matter) so it is entirely possible that the problem is due to a bug in VC++. I need to pass a linked list of structures to a function in the library and the library will free the memory used by the linked list, hence my use of malloc/free instead of new/delete. Here is some example code
//first allocate memory for linked list structure that will be
//passed to the library function
struct blah * ll = (struct blah *)malloc(sizeof(struct blah));
if(ll == 0)
   return -1;

ll->name = (char *)malloc(MAX_STR_LEN);
if(ll->name == 0)
   return -2;
ll->name_length = MAX_STR_LEN;

//now set up some internal data structures in my code
std::string host = "192.168.1.1";
try
{
   char * hostAddr = new char[host.length()+1];
}
catch(std::bad_alloc bae)
{
   return -3;
}

//call library function
//at this point ll->name_length is no longer MAX_STR_LEN but is instead
//a random number
lib_dostuff(ll);   //crashes in here

Using the debugger I have found that the value ll->name_length changes right after the call to new to a value that looks like an address in heap space. Is this a bug in VC++ 5.0 or is it not possible to use new/malloc in the same program?

Share this post


Link to post
Share on other sites
You can use new and malloc() in the same application iff you delete memory allocated with new and free() memory allocated with malloc(). As long as you obey that rule you should be fine. What your problem sounds like is either a buffer overrun or accessing memory after it's already been deallocated.

Share this post


Link to post
Share on other sites
Quote:
Original post by cmptrgear
Is this a bug in VC++ 5.0 or is it not possible to use new/malloc in the same program?


new/malloc in the same program is legal C++.
Since VC++5.0 isn't a C++ compiler, I'm not sure it's legal in the prestandard bastardized form that it implements. From the looks of it, quite possibly not, or you're not showing us all relevant code.

Share this post


Link to post
Share on other sites
Quote:
Original post by cmptrgear
Before I get to my problem let me start off by clearing things up so I dont get a ton of "malloc sux, use new!" I am extending a C++ program to add some more functionality. This program uses functions supplied by a library written in C.


The fact that the library is written in C shouldn't normally prevent you from passing it pointers to memory allocated with new. If you're trying to use a DLL, though, you're in a whole other kind of hell.

Quote:
Also before I continue, this is being developed on VC++ 5.0 (I know, I know...I dont have a choice in the matter) so it is entirely possible that the problem is due to a bug in VC++.


I would like to hear the story of how it comes to be that you don't have a choice in the matter.

Quote:
I need to pass a linked list of structures to a function in the library and the library will free the memory used by the linked list, hence my use of malloc/free instead of new/delete.


Oh, so that's why. Well, that's bad design on the part of the library implementors, then. Library functions that allocate something, expecting you to destroy it, are bad enough (but sometimes the only sane option). But a library function that expects you to allocate something, and will destroy it? WTF?

Share this post


Link to post
Share on other sites
As mentioned above, memory that is "newed" cannot be "freed", it must be "deleted".

I get around this by using a pseudo-new when I have to interface with C code that thinks it can deallocate the memory I allocate:


template<typename T>
T* typed_malloc(int count=1) {
return (T*)malloc(sizeof(T)*count);
};


This doesn't provide construction -- but if I'm using malloc, the free won't destroy the object, so I shouldn't be allocating non-POD objects anyhow.

It does provide type safety and compatability with free.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Quote:
Also before I continue, this is being developed on VC++ 5.0 (I know, I know...I dont have a choice in the matter) so it is entirely possible that the problem is due to a bug in VC++.


I would like to hear the story of how it comes to be that you don't have a choice in the matter.


I'd just like to say that VC++ 5.0 projects don't upgrade to VC6 easily, and come back with a TON of problems in anything after that.

I've also found that if you use malloc in a C++ program that uses new, there are occurances of memory problems that cause crashes, especially once you move the program off the dev machine. Just my experience.

Share this post


Link to post
Share on other sites
Quote:
Original post by Boruki
[...]I'd just like to say that VC++ 5.0 projects don't upgrade to VC6 easily, and come back with a TON of problems in anything after that.[...]
It's like trying to compile a Corman Lisp source file using Perl - VC++ 6.0 and prior predate the standard, so it's no surprise that they don't really deal with C++ (though 6 comes far closer than anything prior).
Unless the project is _HUGE_ (with many years of development behind it, different developers coming and going over the eons, etc), though, it's likely worth it to port the program.
I'm guessing the problem is along the lines of <Mr.Boss>"You're using VC++5 for this project."</Mr.Boss> (or deadlines that preclude porting to C++).

Share this post


Link to post
Share on other sites

This topic is 4198 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this