Re: strcpy_s vs strcpy
On Jul 2, 4:33 am, Trups <Samant.Tru...@gmail.com> wrote:
I have changed my strcpy to strcpy_s for 2005 project. It's fairly
big project and was using strycpy lot of places.
It might helpful to provide a little background information here -
since many C++ programmers are probably not familiar with
"strcpy_s()", and the other routines described in the ISO C
Committee's Technical Report 2. The TR2 document (a draft of which can
be found on the ISO C Committee's web site):
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1225.pdf
describes a "bounds-checking" interface to the Standard C Library.
The program started corrupting the stack and in turn crashing the
application. We have realized that it is due to strcpy_s. We have
changes that to strpcy and then it was fine.
The primary benefit of replacing strcpy() with strcpy_s() calls in a
program, is forcing the programmer to document the size of each
destination buffer that is used in a copy string operation. So the
sensible fix would be to specify the size of the destination buffer
accurately in each call to strcpy_s - rather than to specify no size
at all. Reverting the calls to strcopy_s() back to strcpy() does
nothing to mitigate the danger of buffer overruns, instead, the only
effect is to sweep the entire issue under the rug.
There are some places the destlength was more then whatever size of
deststr. I know it is a mistake but the copy string had character to
copy. So I was thinking it shouldn't crash the project. Isn't that
true?
No. Calling strcpy_s() is likely to fill the entire destination buffer
with bytes - regardless of the length of the string being copied. On
modern processors, copying the bytes into the destination buffer and
checking the string for a nul character - can be completed much more
quickly as two, independent operations than they can be when combined
as a single operation. As the footnote in the ISO document explains:
"This allows an implementation to copy characters from s2 to s1 while
simultaneously checking if any of those characters are null. Such an
approach might write a character to every element of s1 before
discovering that the first element should be set to the null
character."
Example:
deststr[128];
copystr[] = "Test String";
destlength = 256;
strcpy_s(deststr, destlength, copystr);
The program has to ensure that size of destsr is correctly specified
in every call to strcpy_s(). Therefore when copying a string to a
fixed-sized char array, sizeof() should always be used to specify the
size of the destination buffer:
strcpy_s( deststr, sizeof(destr), copystr);
even strcpy_s(deststr, strlen(copystr), copystr); was crashing (I need
to look more for this)
The length of the "copystr" string clearly has no relation to the size
of the deststr buffer. So, regardless whether the above strcpy_s()
call crashes or not - the call is simply not correct. Indeed, passing
strlen(copystr) as the size of the destr buffer defeats the entire
purpose of using a bounds-checking interfaces in the first place.
Bounds cannot be checked unless they are accurately specified.
But is there any known problem with strcpy_s?
Not when used correctly.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]