7 replies to this topic

[bollµ]

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

<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[i], tempVolumePathName, 256, &returnedLength);
this->mStrcpyTCHARPtr(tempVolumePathName, 356, &this->volumePathNames[i]); //volumePathName is just a NUL pointer which I want to //be allocated and copied
};
</code>

thanks

[Endurion]

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.

[Kyall]

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.

[adeyblue]

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.

[L. Spiro]

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

[Washu]

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.

[bollµ]

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!

[e‍dd]

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.