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

On Jul 2, 8:53 am, "Samant.Tru...@gmail.com" <Samant.Tru...@gmail.com>
wrote:
> 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.

Samant.Trupti@gmail.com 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/libr...a9(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.

--
Michael

<Samant.Trupti@gmail.com> wrote in message
news:5f8b04b8-2b21-4fbd-903f-a5567072f16c@34g2000hsf.googlegroups.com...
> 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[i] << "
";
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 ) );
}

Samant.Trupti@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.
> 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 ed you in identifying the problem. That's what it's
supposed to do. In my book, that's a good thing.

On Jul 2, 9:51 am, alasham.s...@gmail.com wrote:
> On Jul 2, 8:53 am, "Samant.Tru...@gmail.com" <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. 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 (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 2, 10:41 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> <Samant.Tru...@gmail.com> wrote in message

> news:5f8b04b8-2b21-4fbd-903f-a5567072f16c@34g2000hsf.googlegroups.com...

> > 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.

For the moment.

> > 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?

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[i] << "
> ";
> 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 s
detect errors like passing the wrong length.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

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

On 2 Jul, 07:53, "Samant.Tru...@gmail.com" <Samant.Tru...@gmail.com>
wrote:
> 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).


--
Nick Keighley