C / C++ / MFC

13-Nov-02 3:45

Is it save to realloc a newed buffer, or do one have to use malloc?

<br />
LPBYTE pBuffer = new BYTE[1024];<br />
pBuffer = realloc(pBuffer,2048);<br />
delete[] pBuffer;<br />
<br />
// can I free(pBuffer) ?<br />

dabs13-Nov-02 3:54

dabs

13-Nov-02 3:54

I believe the result is undefined so you should try to avoid code like this. Might work until one day... probably the day when you are showing your project to a potential customer Smile | :)

Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!

jbarton13-Nov-02 3:55

jbarton

13-Nov-02 3:55

It is undefined when you use realloc on a buffer that you allocated with new.

Probably the best way to do this type of operation is to use a vector instead:

<br />
std::vector<BYTE> myBuffer(1024);   // declare a vector with 1024 elements<br />
myBuffer.resize(2048);   // resize it to 2048 elements<br />
<br />
// no need to free - the vector will clean up after itself...<br />

Best regards,
John

Hugo Hallman13-Nov-02 7:22

13-Nov-02 7:22

if you step into the new-handler, it actually calls malloc.
Do you consider that when stating that it's undefined?
Thank you for your answer.

The reason that I ask, is that I'm writing a specialized buffer, and thus cannot use std::vector.

I am using malloc, but just out of curiosity.

Tim Smith13-Nov-02 7:39

13-Nov-02 7:39

You can not mix and match new/delete with malloc/free/realloc. Just because version of the compiler implemented it using malloc means that the same will work for a different version.

The standard specifically states that delete can only be used with new.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

CPropertyPage Brain Fart!!!

jbarton13-Nov-02 7:50

jbarton

13-Nov-02 7:50

Although the current compiler you are using calls malloc as part of its implementation of the new-handler, this is not specified by the C++ standard, and should not be relied on. Another compiler (or a more recent version of the compiler) can change the implementation so that malloc is not called. The result from calling realloc on a buffer allocated with new is undefined. While it may work with this version of the compiler when allocating a POD, it is not a good practice to rely upon an implementation detail that you have no control over. If you decide that realloc is the only way to go, don't use new for the original allocation - just use malloc.

You should be able to use a vector anywhere that you use a raw allocated buffer. What are you trying to do that you don't think will work with a vector?

Chris Hambleton13-Nov-02 3:45

Chris Hambleton

13-Nov-02 3:45

Hi,

Looks like I'm having a brain fart this morning and can't remember how to cancel the closing of a property sheet.

I have two property pages, and I validate some settings in the CMyPropPage1::OnOk() handler. If the settings are invalid, I display a msgbox to the user and want to leave the property sheet displayed. However, it's closing after the user closes the msgbox! When the settings are invalid, I simply return from the handler (which appears to be wrong...). So, what do I have to do to keep it displayed??

Thanks!

Chris

"No one goes to hell because of their sin, but because of rejecting God's method of salvation: His Son's life for yours..."

"It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams

Re: CPropertyPage Brain Fart!!!

Tony Fontenot13-Nov-02 6:11

Tony Fontenot

13-Nov-02 6:11

Well when OnOK is called in the PropertySheet all the PropertyPageses that have been activated get their OnOK called. That means all the pages have been validated; therefor, no matter what the return is from OnOK on the Sheet it will close. Al least that is my experiance. It may be totally incorrect but it is what I tell myself to feel better. Smile | :)

So what do you do? In all my PropertySheets I validate at the Page level. That way if a page fails then I show message and return there.

Hope it helps.

***********************
Tony Fontenot
Recreational Solutions
tony@recsolutions.com
***********************

MT malloc crasches

Hugo Hallman13-Nov-02 3:43

13-Nov-02 3:43

I'm writing an application with heavy mt.
the app runs for about 20 seconds, and then crashes in a malloc call, either through new or CString operator <<

I HAVE used the mt runtime, and it doesn't help.
the linker complained about libc conflicts, so I exluded it with /NODEFAULTLIB

Is it dangerous to load an mfc dll, from an atl application?

Anyone with a hint?

Tim Smith13-Nov-02 6:18

13-Nov-02 6:18

No. But it is dangerous to have buggy code that trashes memory causing malloc to break.

You software is buggy. Look for buffer overruns or accessing memory that has been freed.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Hugo Hallman13-Nov-02 7:15

13-Nov-02 7:15

Would I be unreasable if I said You where rude?
Just assuming my "buggy" code being a reason, seems - to me - like a habit of writing bad code. (?)
If you have nothing better to write...

Daniel Turini13-Nov-02 7:36

Daniel Turini

13-Nov-02 7:36

No, he was not rude, he was right.
Don't take it personally: everyone writes buggy code. Good professionals find bugs and fix them before shipping to users.

And take his advice, it's not easy to write thread safe code, the number of race conditions in the simplest code is impressive and a buffer overrun is easy.
Just a sample: try doing a strcat on two threads at the same time and you'll have a buffer overrun.

Your incessant rantings indicate you have a brain the size of a pea, and the mental capacity of a bag of hammers. - John Simmons

Tim Smith13-Nov-02 7:43

13-Nov-02 7:43

Well, I was being a little rude. But time and time again I see people blame malloc or some other silly thing for their own bugs.

I always look at the compiler/library last as the source of my problems. In 15 years, I think I have found only 4 compiler/library bugs. The 999,985 other bugs were all my fault. And even that number is probably a gross under-estimation.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Daniel Turini13-Nov-02 7:49

Daniel Turini

13-Nov-02 7:49

Tim Smith wrote:
But time and time again I see people blame malloc or some other silly thing for their own bugs.
The same people that never post a code sample demonstrating the bug.

I know what you feel like, I had a really BIG discussion (may I call it fight?) with a fellow programmer that insisted he wouldn't even look at his code, because the bug was in the COM+ thread pool. "The proof? Use the component as a non-pooled component and everything works ok".
Well, looking 5 minutes at his code I found the bug.

Your incessant rantings indicate you have a brain the size of a pea, and the mental capacity of a bag of hammers. - John Simmons

Tim Smith13-Nov-02 8:10

13-Nov-02 8:10

I have always had the philosophy that between my code and the compiler, only my code can be modified. So there is little point looking at the compiler. Even in the VERY rare case of a compiler problem, your only choice is to modify your code to avoid the problem. :/

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Hugo Hallman16-Nov-02 9:08

16-Nov-02 9:08

Well, I have to admit that I was childish, and appoligize.
I have to eat my pride, and present this subtle bug:

<br />
static void OptimizeAllocSize(DWORD* cLength)<br />
{<br />
	static const int nGranularity = 512;<br />
	// the bug is lack of the commented +1.<br />
	*cLength = (((*cLength)/nGranularity)/*+1*/)*nGranularity;<br />
}<br />

one warner to any buffer class: (MSC)

<br />
_ASSERTE(!m_pBuffer || ( *(LPDWORD)((LPBYTE)m_pBuffer-4)==0xFDFDFDFD ) && ( *(LPDWORD)((LPBYTE)m_pBuffer+m_dwCapacity)==0xFDFDFDFD ));<br />

Hugo Hallman16-Nov-02 9:35