strcpy_s & strncpy_s with char pointers

[Draznar]

I have been tasked fixing deprecations and need some help with some rather newbie problems. Listed below are two examples of some warnings that I need to address.

I am seeking some examples on the proper use of strcpy_s & strncpy_s or a link to some "How To:". One thing that I am trying to figure out is, if I am copying into a char *, how do I determine the 2nd parameter, "numberOfElements : Size of the destination string". At first I was doing sizeof(someCharPointer) but then I realized that would not give me what I want. Please forgive the newbie questions, I don't know if this was the correct forum to ask. Thank you for any assistance.


strcpy example
bool RegKey::EnumerateValues(LPTSTR pszValueName, LPBYTE lpValue, DWORD& dwValueSize, DWORD& dwValueType, const DWORD dwIndex)
{
TCHAR tmpName[2048] = {'\0'};

DWORD dwTmpNameSize = sizeof(tmpName);

LONG lRetValue = RegEnumValue(hTheKey_, dwIndex, tmpName, &dwTmpNameSize, NULL, &dwValueType, lpValue, &dwValueSize);
if(lRetValue == ERROR_NO_MORE_ITEMS)
{
_tcscpy(pszValueName, tmpName);
iLastErrorCode_ = ERROR_NO_MORE_ITEMS;
return false;
}

_tcscpy(pszValueName, tmpName); //To be changed to _tcscpy_s()

return true;
}

strncpy example
bool RegKey::GetValue(LPCTSTR pszValueName, LPTSTR pszValue, DWORD& dwValueLength)
{
TCHAR* tmpBuffer = new TCHAR[dwValueLength + 1];
memset(tmpBuffer, 0, dwValueLength * sizeof(TCHAR));

_tcsncpy(pszValue, tmpBuffer, dwValueLength); //To Be changed to _tcsncpy_s()
delete [] tmpBuffer;
tmpBuffer = NULL;

iLastErrorCode_ = ERROR_SUCCESS;
return true;
}

[Lindley]

If you just replace all instances of strcpy with strncpy, you'll be fine. There's no need to get into MS's annoying _s functions.

Of course, the above is wrong because pszValueName is a TCHAR*, not a char*. So you should be using _tcsncpy() instead. Otherwise, a switch between a Unicode build an a non-unicode build would break your program.

Also of course, you'd do much better to use std::string or std::wstring in the first place. I think there's an MS "t" version of that somewhere too.....

[Draznar]

I have to use MS's _s functions because my project manager says so T_T. I'd love to just use std::string, life would be much easier, but I am not allowed to change that, just "leave it as is, just get it to work with the _s functions".

Also the lack of _tcsncpy() was a copy mistake on my part, its fixed as it should be.

[Lindley]

Eh, that sucks. You sure you can't just define _CRT_SECURE_NO_DEPRECATE? That's what I do....

Anyway, in answer to your question, it's impossible to know how much space is available behind the pointer unless that's a parameter passed into the function. (That would be the reason the _s functions exist at all in many cases.)

There is a very hackish option which *might* work, but only if you can guarantee that the pointer is to the beginning of a block of memory returned by malloc() or calloc(). That's a very iffy requirement, so I'm not going to mention the method.....

[TheCPUWizard]

A good majority of companies are mandating the elimination of the "unsafe" string/memory routines, and enforcing the "_s" extenstion with the deprecation.

I fully support this - for environments where there is a commitment to using Microsoft Compilere - simply because the number of security defects and other bugs that are caused by logic errors in this area.

Of the 10+ conversion I have been envolved with (all large enterpise level projects) EVERY SINGLE ONE revealed at least one bug that was caused by an improper "strcpy" or related error..

Following all of the recommmendations here are strongly recommended for ANY application which is going to be compiled on Microsoft Compillers and do not require portability.