mystrcpy

Started by
7 comments, last by LessBread 18 years, 2 months ago

char *mystrcpy(char *strDest, const char *strSrc)
{
	char *address=strDest;
	while(*strDest++=*strSrc++);
	*strDest++='\0';
	return address;
}

int _tmain(int argc, _TCHAR* argv[])
{
	char a[]="awp";
	char b[]="abcdefghigklmn";
	out<<mystrcpy(a,b);
}


it is answer by a doctor to write a char *mystrcpy(char *strDest, const char *strSrc). I think it is dangous, if strSrc < strDest, strSrc will be overlay. [Edited by - LessBread on January 26, 2006 3:54:40 AM]
Advertisement
I'm not sure what you are asking.

If you are running into a problem with this, it is because of this:

char a[]="awp";char b[]="abcdefghigklmn";


You are trying to copy 15 characters (including \0) from b into an area of memory that only has 4 bytes reserved. You should be getting segmentation faults whenever you try it.

You solution could be to reallocate memory for 'a' before writing to it, or to measure it and truncate 'b' appropriately.
We''re sorry, but you don''t have the clearance to read this post. Please exit your browser at this time. (Code 23)
You could probably get away with 15 characters due to the compiler padding the string to a default length, but that doesn't make the usage safe. It's up to the programmer to make certain the destination is large enough. The code for mystrcpy isn't very different from the code for strcpy.

If the length of strSrc < the length of strDest, there won't be any overlay due to the null termination of the string. Whatever was in strDest beyond the length of strSrc will simply be lost.

At any rate, these routines aren't truly safe anyway.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
also note that the code isn't minimal. the third line within the cpy function is redundant. if you're expecting the second argument to be a C null terminated string.
for an explanation see stroustrup, the c++ programming language, chapter 6.2.5, 3rd edition (should be the same in all the other ones)
Quote:Original post by Anonymous Poster
also note that the code isn't minimal. the third line within the cpy function is redundant. if you're expecting the second argument to be a C null terminated string.
Yes the destination string is double-null terminated, being more dangerous than terminating with 1 null char because the programmer may only have a buffer big enough for one null char.

I have written my own strcpy routines before and it was for a valid purpose. I was working with an embedded C compiler and using a mixture of near and far pointers. althought there were functions like strcpy_n_f for near to far etc, they didn't actually work! Yes were were using them correctly, and yes we were calling the right ones.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
Why do people keep calling C-strings "null-terminated"? The name of the '\0' character is NUL, and nothing else. So, the correct name is nul-terminated.

Programmers these days....
Quote:Original post by Anonymous Poster
Why do people keep calling C-strings "null-terminated"? The name of the '\0' character is NUL, and nothing else. So, the correct name is nul-terminated.

Programmers these days....


Because "NUL" is simply the abbreviation for the word "NULL" which was used in the ASCII standard character set reference table. Similarly, it's called backspace, not just BS; a carriage return, not just a CR; and the thing that old terminal printers used to make noise was a bell, not a BEL. Apparently, programmers these days are less prone to nitpicking.
#define NULL (void *)0

Ok. So NULL is a void pointer and NUL is a char. They both evaluate to 0.

I suppose it's because programmers these days aren't as familiar with ASCII code as were programmers from days of yore... [smile]
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man

This topic is closed to new replies.

Advertisement