Re: TCHAR, terminating '\0' and _tcscat
From: Doug Harrison [MVP] (dsh_at_mvps.org)
Date: 08/10/04
- Next message: Srinivasan.S: "storing DIB (Device Independent bitmaps) in compressed format"
- Previous message: David Mair: "Re: how to stop time consuming instructions (malloc)"
- In reply to: GuitarBill: "Re: TCHAR, terminating '\0' and _tcscat"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 09 Aug 2004 23:15:10 -0500
GuitarBill wrote:
>tcsncat won't always append null terminator.
>When declaring char arrays, its always a good idea to initialize with zeros
>so you know whatever happens it will always be null terminated:
>
>TCHAR newstring[250] = {0};
That doesn't guarantee newstring "will always be nul-terminated".
>And as other poster says, what if '.' isn't there? You should always check:
>if (pdot)
> _tcsncpy(newstring,lpFileName,pdot-lpFileName);
If pdot-lpFileName >= 250, newstring will not be nul-terminated. If it's >
250, you have a buffer overrun. In both these cases, your initialization of
newstring is pure inefficiency, as you would observe exactly the same
behavior were you to eliminate it. It makes no sense to do a strncpy which
doesn't use the length of the destination string; it kinda misses the point
altogether. This is not the proper function to use. Here's one way to fix
it:
int len = pdot-lpFileName;
// Avoid magic numbers, but since it was used above...
if (len < 250)
*std::copy(lpFileName, pdot, newstring) = 0;
else
handle error
This std::copy call will copy the sequence [lpFileName, pdot) to newstring
and nul-terminate newstring. Note also that I don't need to initialize
newstring with 250 useless zeroes for this to work.
The function strncpy rarely makes any sense at all. If the source string is
longer than its length argument, it leaves the destination array truncated
and without a nul-terminator, and if it copies fewer characters than the
maximum allowed, it fills the remainder of the destination with zeroes. It's
quite the bizarre function.
>Personally I'd prefer to do it the other way around, and avoid the pointer
>arithmetic:
> _tcsncpy(newstring, lpFileName, 249);
>TCHAR *pdot = _tcsrchr(netwstring,'.');
>if (pdot)
> *pdot = 0;
You should be concerned with long filenames and truncation. What if the path
was:
C:\dir.ext\filename_pad_out_to_249_chars.oops
Your code relies on the fact you initialized newstring as you did above.
Logically, does it makes sense to fill an array with 250 zeroes and then
pretend that its size is only 249 characters? Moreover, what if the path
was:
C:\x.pad_out_to_1000_chars
Logically, does it make sense to copy (in this case) 249 characters, and
then throw away all but the first 4, just to avoid simple pointer
arithmetic?
-- Doug Harrison Microsoft MVP - Visual C++
- Next message: Srinivasan.S: "storing DIB (Device Independent bitmaps) in compressed format"
- Previous message: David Mair: "Re: how to stop time consuming instructions (malloc)"
- In reply to: GuitarBill: "Re: TCHAR, terminating '\0' and _tcscat"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
