//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
new/malloc incompatability?
Author
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
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?
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.
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.
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?
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:
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.
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.
Quote:Original post by ZahlmanQuote: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.
Quote:Original post by BorukiIt'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).
[...]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.[...]
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++).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
