Strcpy_s and strcpy - comp.lang.c++

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/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. -- 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 helped 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[] =3D "Test String"; > > destlength =3D 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=E9e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, 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[] =3D "Test String"; > > destlength =3D 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] =3D '\0'; > } > > void DispMemory( char* Memory, size_t Size ) > { > std::cout << Memory << "\n"; > for ( size_t i =3D 0; i < Size; ++i ) > std::cout << std::hex << (unsigned int)(unsigned char)Memory[i] <= < " > "; > std::cout << "\n"; > } > int main() > { > char Buffer[12]; > char String[] =3D "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. -- James Kanze (GABI Software) email:james.kanze@gmail.com Conseils en informatique orient=E9e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On 2 Jul, 07:53, "Samant.Tru...@gmail.com" <Samant.Tru...@gmail.com> wrote: > Hi, > > =A0 I have changed my strcpy to strcpy_s for 2005 project. =A0It's fairly > big project and was using strycpy lot of places. > The program started corrupting the stack and in turn crashing the > application. =A0We have realized that it is due to strcpy_s. =A0We have > changes that to strpcy and then it was fine. > There are some places the destlength was more then whatever size of > deststr. =A0I know it is a mistake but the copy string had character to > copy. =A0So I was thinking it shouldn't crash the project. Isn't that > true? > > Example: > deststr[128]; > copystr[] =3D "Test String"; > destlength =3D 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