wcscpy_s issues [modified]

Nish Nishant

There's no problem in the snippet of code you have shown. The error, presumably, lies elsewhere. Regards, Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)

Viorel

Since _tcscpy_s is expanded to wcscpy_s call in Unicode version, you must specify the size of destination buffer in 2-byte unicode characters, not in bytes. Universal solution can look like this:

_tcscpy_s(array,
sizeof(array) / sizeof(TCHAR),
strText);

You got halts even if the source string was short enought, because -- in Debug version -- this function fills the buffer with 0xFD value. -- modified at 11:33 Friday 2nd June, 2006

David Crow

big_denny_200 wrote:

But the program halts and hangs, when performs _tcscpy_s method.

How are you verifying this?

"The largest fire starts but with the smallest spark." - David Crow

Zac Howland

Try explicitly casting the CString object: TCHAR array[100]; CString strText = _T("Cool"); _tcscpy_s(array,//Location of destination string buffer sizeof(array),// Size of the destination string buffer. (LPCTSTR)strText//Null-terminated source string buffer. ); If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

Nemanja Trifunovic

big_denny_200 wrote:

But the program halts and hangs, when performs _tcscpy_s method.

(Offtopic sarcasm) Glad to see these "safe" functions in action.

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Viorel

(Actually, explicit casting from CString to LPCTSTR is not required even in printf-like calls -- at least in VS 6.0).

Zac Howland

It shouldn't be, but I've run into problems with it converting (implicitly) to char* instead of wchar_t* when I didn't explicitly cast it. Looking back at the code again, I think he will run into another problem though. In non-UNICODE builds, he shouldn't notice anything, but in UNICODE builds, the sizeof(array) will actually return twice the size of the actual buffer. I believe the wstcpy_s function requires array size in elements, not bytes (I'll have to double-check that though). If I'm correct, he would just need to change that line from sizeof(array) to sizeof(array) / sizeof(TCHAR). If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

big_denny_200

Could you be more explicit ? MSDN says, that second parameter of wcscpy_s must specify size of destination buffer in bytes, therefore in Unicode build destination size will be 100 * sizeof(TCHAR) (which is equal to sizeof(array)), but in you case it will be 100(which is not the size of destination buffer) I am little confused. thanks -- modified at 12:02 Friday 2nd June, 2006

big_denny_200

What is happening ? I am replying to Viorel Bejan and this post gooes in reply to Zac Howland's post :confused:

Viorel Bejan wrote:

Since _tcscpy_s is expanded to wcscpy_s call in Unicode version, you must specify the size of destination buffer in 2-byte unicode characters, not in bytes. Universal solution can look like this: _tcscpy_s(array, sizeof(array) / sizeof(TCHAR), strText); You got halts even if the source string was short enought, because -- in Debug version -- this function fills the buffer with 0xFD value.

Could you be more explicit ? MSDN says, that second parameter of wcscpy_s must specify size of destination buffer in bytes, therefore in Unicode build destination size will be 100 * sizeof(TCHAR) (which is equal to sizeof(array)), but in you case it will be 100(which is not the size of destination buffer) I am little confused. thanks -- modified at 12:02 Friday 2nd June, 2006 -- modified at 12:04 Friday 2nd June, 2006

Nish Nishant

Nemanja Trifunovic wrote:

(Offtopic sarcasm) Glad to see these "safe" functions in action.

:-D Regards, Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)

Nish Nishant

Viorel Bejan wrote:

You got halts even if the source string was short enought, because -- in Debug version -- this function fills the buffer with 0xFD value.

But in this specific case, it's not bad enough to cause a halt - since he has a 100 byte buffer and a 5 character string. Regards, Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)

George L Jackson

Actually, it says the second parameter of wcscpy_s must specify size of destination buffer in words (in bytes for non-Unicode). Thus, it is the size in characters and not size in bytes! If you are using a statically-allocated array as a destination, you can use the _countof macro instead of sizeof. However, sizeof(array) / sizeof(TCHAR) also returns the correct size.

big_denny_200

thanks, I did not pay attention to the WORD

George L Jackson

Word, man! :)

georgeraafat

According to: http://msdn2.microsoft.com/en-us/library/td1esda9.aspx[^] the sizeof(array) should correspond to the number of 'characters' - not 'bytes'. So - in case of ANSI, it's bytes. In case of unicode, it's words (2-bytes). When the code you listed compiles for unicode, sizeof(array) is 200 - which is double the actual number of characters. Note that _tcscpy_s() zeros out the buffer after copying... and that's when you get the buffer overrun. You can find that out by stepping into _tcscppy(). You can use (sizeof(array)/sizeof(array[0])) or the _countof() macro. gmileka