Strcpy_s and strcpy

[Samant.Trupti]

Hi,

I have changed my strcpy to strcpy_s for 2005 project. It's fairly
big project and was using strycpy lot of places.
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.
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?

Example:
deststr[128];
copystr[] = "Test String";
destlength = 256;

strcpy_s(deststr, destlength, copystr);
even strcpy_s(deststr, strlen(copystr), copystr); was crashing (I need
to look more for this)

But is there any known problem with strcpy_s?
Thanks
Trupti

 

[alasham.said]

Hi,

I have changed my strcpy to strcpy_s for 2005 project. It's fairly
big project and was using strycpy lot of places.
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.
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?

Example:
deststr[128];
copystr[] = "Test String";
destlength = 256;

strcpy_s(deststr, destlength, copystr);
even strcpy_s(deststr, strlen(copystr), copystr); was crashing (I need
to look more for this)

But is there any known problem with strcpy_s?
Thanks
Trupti

Hello,

Perhaps I misunderstand the question, but in any case, 'destlength'
should refer to the allocated size of the destination buffer, and
should not be larger, otherwise memory corruption may occur.

Also, I believe that 'strcpy_s' is not yet part of the standard, so a
Microsoft forum could be more appropriate for discussing this issue.

Regards.

 

[Michael DOUBEZ]

(e-mail address removed) a écrit :

Hi,

I have changed my strcpy to strcpy_s for 2005 project. It's fairly
big project and was using strycpy lot of places.
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.
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?

Example:
deststr[128];
copystr[] = "Test String";
destlength = 256;

strcpy_s(deststr, destlength, copystr);

If you are under windows:

The debug versions of these functions first fill the buffer with 0xFD.
To disable this behavior, use _CrtSetDebugFillThreshold.

See: http://msdn.microsoft.com/en-us/library/td1esda9(VS.80).aspx

So indeed, you will have 128 bytes of corruption with this code.

even strcpy_s(deststr, strlen(copystr), copystr); was crashing (I need
to look more for this)

Perhaps you meant:
strcpy_s(deststr, strlen(copystr)+1, copystr);

To copy the whole string (add one to make place for the terminal 0)

Does it crash with this code ?

But is there any known problem with strcpy_s?

I don't know, I use string
And strcpy_s is not implemented on my platform.

 

[Jim Langston]

Hi,

I have changed my strcpy to strcpy_s for 2005 project. It's fairly
big project and was using strycpy lot of places.
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.
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?

Example:
deststr[128];
copystr[] = "Test String";
destlength = 256;

strcpy_s(deststr, destlength, copystr);
even strcpy_s(deststr, strlen(copystr), copystr); was crashing (I need
to look more for this)

But is there any known problem with strcpy_s?

A test program shows that strcpy_s is doing some nasty business at least in
debug. Output of the following program is:

XXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 0
Copy
43 6f 70 79 0 58 58 58 58 58 58 0
Copy
43 6f 70 79 0 fe fe fe fe fe fe fe

In Release it is differnent:

XXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 0
Copy
43 6f 70 79 0 58 58 58 58 58 58 0
Copy
43 6f 70 79 0 58 58 58 58 58 58 0

#include <iostream>

void ClearMemory( char* Memory, size_t Size )
{
memset( Memory, 'X', Size - 1 );
Memory[Size - 1] = '\0';
}

void DispMemory( char* Memory, size_t Size )
{
std::cout << Memory << "\n";
for ( size_t i = 0; i < Size; ++i )
std::cout << std::hex << (unsigned int)(unsigned char)Memory << "
";
std::cout << "\n";
}

int main()
{
char Buffer[12];
char String[] = "Copy";

ClearMemory( Buffer, sizeof( Buffer ) );
DispMemory( Buffer, sizeof( Buffer ) );

strcpy( Buffer, String );
DispMemory( Buffer, sizeof( Buffer ) );

ClearMemory( Buffer, sizeof( Buffer ) );
strcpy_s( Buffer, sizeof( Buffer ), String );
DispMemory( Buffer, sizeof( Buffer ) );
}

 

[Eberhard Schefold]

I have changed my strcpy to strcpy_s for 2005 project. It's fairly
big project and was using strycpy lot of places.
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.

It is "fine" as long as your source string is short enough not to
overwrite the falsely advertised target buffer. The day when you're
presenting the application to your biggest potential customer, the
string will happen be larger, overrun the buffer and lead to random
erratic behavior of your application. Or it will create a target vector
for the infamous "buffer overrun" types of security attacks. No longer
so fine.

strcpy_s has helped you in identifying the problem. That's what it's
supposed to do. In my book, that's a good thing.

 

[James Kanze]

On Jul 2, 8:53 am, "(e-mail address removed)" <[email protected]>
wrote:

I have changed my strcpy to strcpy_s for 2005 project. It's
fairly big project and was using strycpy lot of places. 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. 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?
Example:
deststr[128];
copystr[] = "Test String";
destlength = 256;
strcpy_s(deststr, destlength, copystr);
even strcpy_s(deststr, strlen(copystr), copystr); was crashing (I need
to look more for this)
But is there any known problem with strcpy_s?

Perhaps I misunderstand the question, but in any case,
'destlength' should refer to the allocated size of the
destination buffer, and should not be larger, otherwise memory
corruption may occur.

Also, I believe that 'strcpy_s' is not yet part of the
standard, so a Microsoft forum could be more appropriate for
discussing this issue.

It's part of a TR (or something similar) for C. I doubt that it
will ever be part of C++, since we already have much better and
safer tools (std::string).

 

[James Kanze]

For the moment.

Garbage in, garbage out. If you lie to the function, you can't
expect it to behave normally.

Example:
deststr[128];
copystr[] = "Test String";
destlength = 256;
strcpy_s(deststr, destlength, copystr);
even strcpy_s(deststr, strlen(copystr), copystr); was crashing (I need
to look more for this)
But is there any known problem with strcpy_s?

A test program shows that strcpy_s is doing some nasty
business at least in debug. Output of the following program
is:

XXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 0
Copy
43 6f 70 79 0 58 58 58 58 58 58 0
Copy
43 6f 70 79 0 fe fe fe fe fe fe fe

In Release it is differnent:

XXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 0
Copy
43 6f 70 79 0 58 58 58 58 58 58 0
Copy
43 6f 70 79 0 58 58 58 58 58 58 0

#include <iostream>

void ClearMemory( char* Memory, size_t Size )
{
memset( Memory, 'X', Size - 1 );
Memory[Size - 1] = '\0';
}

void DispMemory( char* Memory, size_t Size )
{
std::cout << Memory << "\n";
for ( size_t i = 0; i < Size; ++i )
std::cout << std::hex << (unsigned int)(unsigned char)Memory << "
";
std::cout << "\n";
}

int main()
{
char Buffer[12];
char String[] = "Copy";

ClearMemory( Buffer, sizeof( Buffer ) );
DispMemory( Buffer, sizeof( Buffer ) );

strcpy( Buffer, String );
DispMemory( Buffer, sizeof( Buffer ) );

ClearMemory( Buffer, sizeof( Buffer ) );
strcpy_s( Buffer, sizeof( Buffer ), String );
DispMemory( Buffer, sizeof( Buffer ) );
}

Looks fine to me. I'd consider this a feature, if it helps
detect errors like passing the wrong length.

 

[Samant.Trupti]

This indeed a feature. Wanted to understand how it's done.
I got my doubt clear
Thanks
Trupti

 

[Nick Keighley]

Hi,

  I have changed my strcpy to strcpy_s for 2005 project.  It's fairly
big project and was using strycpy lot of places.
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.
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?

Example:
deststr[128];
copystr[] = "Test String";
destlength = 256;

strcpy_s(deststr, destlength, copystr);
even strcpy_s(deststr, strlen(copystr), copystr); was crashing (I need
to look more for this)

But is there any known problem with strcpy_s?

from MSDN: "The strcpy_s function copies the contents in the address
of strSource, including the terminating null character, to the
location specified by strDestination. The destination string must be
large enough to hold the source string, including the terminating null
character. The behavior of strcpy_s is undefined if the source and
destination strings overlap."

I assume you are supposed to know the size of the destination buffer
(which is not unreasonable).