how to use strncpy()?

If I understood right, it must be used like this:
#define MAX 4
char a[MAX];
strncpy(a,b,MAX-1);
a[MAX-1] = 0; // this line is required, isn't it?

Is it correct?

Ulrich
Wed Feb 08 06:44:22 CST 2006

DR wrote:
> If I understood right, it must be used like this:
> #define MAX 4
> char a[MAX];
> strncpy(a,b,MAX-1);
> a[MAX-1] = 0; // this line is required, isn't it?
>
> Is it correct?

Yes, even the 'safe' strncpy is easy to get wrong by forgetting the last
line, which is why you should consider using std::string or std::wstring
even.

Uli

Alex
Wed Feb 08 06:57:48 CST 2006

DR wrote:
> If I understood right, it must be used like this:
> #define MAX 4
> char a[MAX];
> strncpy(a,b,MAX-1);
> a[MAX-1] = 0; // this line is required, isn't it?
>
> Is it correct?

I'd secons Ulrich's advise. try to avoid str* functions. Use
classes instead.

Good article about XXXncpy functions:

"How can code that tries to prevent a buffer overflow end up
causing one?"
http://blogs.msdn.com/oldnewthing/archive/2005/01/07/348437.aspx

DR
Wed Feb 08 10:57:21 CST 2006

This function should be save? What do you think?

LPCSTR my_strncpy(LPSTR a, LPCSTR b, int cnt)
{
if (!cnt) return a; // or maybe return 0
a[cnt-1] = 0;
return strncpy(a,b,cnt-1);
}

> classes instead.
>
> Good article about XXXncpy functions:
>
> "How can code that tries to prevent a buffer overflow end up causing one?"
> http://blogs.msdn.com/oldnewthing/archive/2005/01/07/348437.aspx
>

Alex
Wed Feb 08 11:52:21 CST 2006

DR wrote:
> This function should be save? What do you think?
>
> LPCSTR my_strncpy(LPSTR a, LPCSTR b, int cnt)
> {
> if (!cnt) return a; // or maybe return 0
> a[cnt-1] = 0;
> return strncpy(a,b,cnt-1);
> }
>


I think that reinventing the wheel is not rewarding
activity. There is plenty of string facilities nowadays when
developing for Windows platform. You can choose between:

1. MFC/ATL: CString
2. STL: std::string/std::wstring
3. PSDK: lstrcpyn/StrCmpN/StringCbCopyN
4. VC2005, CRT: strncpy_s
5. VC, comutil.h: _bstr_t

This is what you have right after fresh installation of VC.
If you use third party library, then it's likely that there
will be even more string classes.

Tom
Wed Feb 08 13:19:43 CST 2006

The think I like the most about the _tcscpy_s() implementation is that it
works well with arrays that are allocated on the stack so, for most things,
it's pretty easy to use. I try not to use str___ functions any more than I
have to (mostly for old libraries that I don't want to rewrite), but it's
nice that the new implementations were so easy to, um, implement.

Tom

"Alex Blekhman" <tkfx.N05P4M@yahoo.com> wrote in message
news:%23JiJrhNLGHA.1028@TK2MSFTNGP11.phx.gbl...
> DR wrote:
>> This function should be save? What do you think?
>>
>> LPCSTR my_strncpy(LPSTR a, LPCSTR b, int cnt)
>> {
>> if (!cnt) return a; // or maybe return 0
>> a[cnt-1] = 0;
>> return strncpy(a,b,cnt-1);
>> }
>>
>
>
> I think that reinventing the wheel is not rewarding activity. There is
> plenty of string facilities nowadays when developing for Windows platform.
> You can choose between:
>
> 1. MFC/ATL: CString
> 2. STL: std::string/std::wstring
> 3. PSDK: lstrcpyn/StrCmpN/StringCbCopyN
> 4. VC2005, CRT: strncpy_s
> 5. VC, comutil.h: _bstr_t
>
> This is what you have right after fresh installation of VC. If you use
> third party library, then it's likely that there will be even more string
> classes.
>

Tom
Wed Feb 08 13:26:05 CST 2006

Hi DR ,

You could already use strcpy_s() this same way and the only difference would
be that it wouldn't put a numeric 0 in your last count item. However, it
would safely know the size of the buffer in many occasions:

TCHAR myBuff[20];

_tcscpy_s(myBuff,_T("Test Data"));

or

_tcscpy_s(myBuff, _countof(MyBuff), _T("Test Data"));

Both are safe because of the template implementation. IOW, there is no
longer any really good reason to implement your own version and even if you
do the new compiler will gripe about how strcpy() is deprecated so you'll
have to put:

#pragma warning (disable : 4996)

all over in your code :o)

Tom

"DR" <dr1234@yahoo.com> wrote in message
news:e$P0BDNLGHA.604@TK2MSFTNGP14.phx.gbl...
> This function should be save? What do you think?
>
> LPCSTR my_strncpy(LPSTR a, LPCSTR b, int cnt)
> {
> if (!cnt) return a; // or maybe return 0
> a[cnt-1] = 0;
> return strncpy(a,b,cnt-1);
> }
>
>> classes instead.
>>
>> Good article about XXXncpy functions:
>>
>> "How can code that tries to prevent a buffer overflow end up causing
>> one?"
>> http://blogs.msdn.com/oldnewthing/archive/2005/01/07/348437.aspx
>>
>
>

Ulrich
Thu Feb 09 03:28:41 CST 2006

DR wrote:
> This function should be save? What do you think?
>
> LPCSTR my_strncpy(LPSTR a, LPCSTR b, int cnt)
> {
> if (!cnt) return a; // or maybe return 0
> a[cnt-1] = 0;
> return strncpy(a,b,cnt-1);
> }
>

Save in what way? I'd start off making a few unittests, further I would
document its prerequisites (in documentation and with assertions in code)
as well as its behaviour in general. Lastly, there is IMHO no reason to use
win32 typedefs here and this function will always create warnings when the
third argument comes from a sizeof or strlen() or something similar because
those return a size_t, which is unsigned and possibly larger than an int.

Uli