TCHAR * causing heap corruption

Started by
6 comments, last by the_edd 12 years, 1 month ago
Hi guys!

I'm not really sure why, but my custom strcpy and strAlloc functions that operate on Tchars appear to be corrupting the heap (VS 2010 gives me an error message saying so).
Thanks for the help smile.png

<code>

TCHAR* volumeCircle::mAllocTCHARPtr(TCHAR *src, int maxSrcLength, TCHAR **dstPtr){
size_t length;
StringCchLength(src, maxSrcLength, &length);
*dstPtr = (TCHAR *)malloc(length);
return *dstPtr;
};


TCHAR* volumeCircle::mStrcpyTCHARPtr(TCHAR *src, int maxSrcLength, TCHAR **dst){
volumeCircle::mAllocTCHARPtr(src, maxSrcLength, dst);
return _tcscpy(*dst,src);
};
</code>

this is where I call the function:
<code>

for(int i = 0; i < this->numVolumes; i++){
TCHAR tempVolumePathName[256];
GetVolumePathNamesForVolumeName(this->systemVolumeNames, tempVolumePathName, 256, &returnedLength);
this->mStrcpyTCHARPtr(tempVolumePathName, 356, &this->volumePathNames); //volumePathName is just a NUL pointer which I want to //be allocated and copied
};
</code>

thanks :)

a WIP 2d game engine: https://code.google.com/p/modulusengine/

English is not my first language, so do feel free to correct me :)

Advertisement
The f*ck! Why on earth are you doing that weird mallocery? Can't you use std::wstring?

Also, what charset setting are you using? Unicode or multi byte?
TCHAR is a typedef for either char or wchar_t

For the corruption: You're passing 356 as max length, but your array is only 256 units.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

Heap corruption happens when you overwrite a buffer, or when you try to delete a pointer you've already deleted. If you try to write to a deleted pointer you get an access violation. And if you new an allocated value you get a memory leak.

600px-The_More_You_Know_2011.png
I say Code! You say Build! Code! Build! Code! Build! Can I get a woop-woop? Woop! Woop!

StringCchLength(src, maxSrcLength, &length);
*dstPtr = (TCHAR *)malloc(length);

You ask for the length in characters, you alloc the length in bytes. With TCHAR you have a 50% chance these are not the same. If they are not, you only allocate half of what you need. The code needs to add 1 to length as it doesn't account for a null terminator, and multiply the result by sizeof(TCHAR), or it needs to use the sane C++ default of std::(w)string as Endurion suggested.
And by the way, I may sound like a broken record but it seems no matter how many times I say this the next guy just does it again.

Stop using 256 for paths. MAX_PATH (260, WinAPI) and PATH_MAX (1,024, everything else) are defined for a reason.
Nothing personal, just a pet peeve.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

Honestly, don't even use that, if you're going that route use UNC paths. Stop being stuck in the past and using non-UNC paths. The number of windows applications that still can't handle paths longer then MAX_PATH, despite the intrinsic filesystem support is simply astonishing.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

ah, okay. thanks for the input.
adeyblue: ty for that :) It fixed my problem.
and washu, I changed the temp array size to 4096 xD

I'm just doing it to try and use the windows API >.>
anyway, Ty all!

a WIP 2d game engine: https://code.google.com/p/modulusengine/

English is not my first language, so do feel free to correct me :)


Honestly, don't even use that, if you're going that route use UNC paths. Stop being stuck in the past and using non-UNC paths. The number of windows applications that still can't handle paths longer then MAX_PATH, despite the intrinsic filesystem support is simply astonishing.

Indeed.

This topic is closed to new replies.

Advertisement