strcpy - my implementation

[arnuld]

I have created my own implementation of strcpy library function. I would
like to have comments for improvements:
/* My version of "strcpy - a C Library Function */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

enum { ARRSIZE = 101 };

char* my_strcpy( char*, char* );

int main( int argc, char** argv )
{
char* pc;

char arr_in[ARRSIZE];
char arr_out[ARRSIZE];

memset( arr_in, '\0', ARRSIZE );
memset( arr_out, '\0', ARRSIZE );
if( 2 != argc )
{
perror("USAGE: ./exec \" your input \"\n");
exit( EXIT_FAILURE );
}
else
{
strcpy( arr_in , argv[1] );
}

pc = my_strcpy( arr_out, arr_in );

while( *pc )
{
printf("*pc = %c\n", *pc++);
}

return EXIT_SUCCESS;
}

char* my_strcpy( char* arr_out, char* arr_in )
{
char* pc;

pc = arr_out;

while( (*arr_out++ = *arr_in++) ) ;

return pc;
}
=============== OUTPUT =============== =======

[arnuld@dune ztest]$ gcc -ansi -pedantic -Wall -Wextra check_STRCPY.c
[arnuld@dune ztest]$ ./a.out like
*pc = l
*pc = i
*pc = k
*pc = e
[arnuld@dune ztest]$

It works fine without troubles. Now if you change the last return call in
my_strcpy from "return pc" to return "return arr_out", then while loop in
main() will not print anything at all. I really did not understand it.
Using thr array name will give a pointer to its 1st element but int htis
case it is giving a pointer to its last element. Why ? Thats why I
introduced the extra "char* pc" in first place.


--
www.lispmachine.wordpress.com
my email is @ the above blog.
Google Groups is Blocked. Reason: Excessive Spamming

[Richard Heathfield]

Bartc said:

>
"Ian Collins" <ia******@hotma il.comwrote in message
news:6i******** ****@mid.indivi dual.net...

>arnuld wrote:

>>>

<snip>

>> while( (*arr_out++ = *arr_in++) ) ;

return pc;
}

>The inner parentheses in the while loop
are superfluous.

I thought this was sometimes used to stop the compiler warning about
using "=" instead of "==".

Right, and in that respect the parentheses are not superfluous in code
intended to be compiled by implementations that recognise that construct
as having that meaning. They /are/ superfluous from a C perspective,
because they can be removed without affecting the semantics of the code.
So whether or not they are truly superfluous really depends on what you
mean by "superfluou s".

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Sjoerd]

On Mon, 08 Sep 2008 07:55:15 +0000, Richard Heathfield wrote:

char arr_in[ARRSIZE] = {0};
char arr_out[ARRSIZE] = {0};

What does this do? How does it work? You seem to initialize only one
element of the array, so I expect that it does not set the whole content
of the array to 0.

[pete]

Richard Heathfield wrote:

arnuld said:

>char* my_strcpy( char* arr_out, char* arr_in )

Better: char *my_strcpy(char * arr_out, const char *arr_in)

>{
char* pc;

pc = arr_out;

You could change that to

char *const pc = arr_out;

> while( (*arr_out++ = *arr_in++) ) ;

/* I would go even further than just extra parentheses: */

while ((*arr_out++ = *arr_in++) != '\0') {

/*
** There are some coding guidelines against writing
** an entire loop with only an empty statement on one line.
** Some programmers, including myself,
** always use a compound statement
** with an if statement or a loop statement.
*/
;
}

>>
return pc;
}

http://www.psgd.org/paul/docs/cstyle/cstyle.htm
http://www.psgd.org/paul/docs/cstyle/cstyle08.htm

--
pete

[James Kuyper]

Sjoerd wrote:

On Mon, 08 Sep 2008 07:55:15 +0000, Richard Heathfield wrote:

> char arr_in[ARRSIZE] = {0};
char arr_out[ARRSIZE] = {0};

What does this do? How does it work? You seem to initialize only one
element of the array, so I expect that it does not set the whole content
of the array to 0.

Your expectation is incorrect. If you explicitly initialize any elements
of an array or any members of a structure, all of the remaining array
elements or structure members are implicitly zero-initialized.

[pete]

Sjoerd wrote:

On Mon, 08 Sep 2008 07:55:15 +0000, Richard Heathfield wrote:

> char arr_in[ARRSIZE] = {0};
char arr_out[ARRSIZE] = {0};

What does this do? How does it work? You seem to initialize only one
element of the array, so I expect that it does not set the whole content
of the array to 0.

That the way it seems
if you don't know the relevant parts of the C language.

char arr_in[ARRSIZE] = "";

is yet another way to initialize the entire array to null characters.

A short initializer, sets the remaining elements
as though they were each initilzed with {0}.

char array[10] = {'A'};
or
char array[10] = "A";

gives you an array with one element equal to ('A'),
followed by nine array elements, each equal to ('\0').

--
pete

[Nate Eldredge]

Richard Heathfield <rj*@see.sig.in validwrites:

arnuld said:

>I have created my own implementation of strcpy library function. I would
like to have comments for improvements:

[...]

>>
int main( int argc, char** argv )
{
char* pc;

char arr_in[ARRSIZE];
char arr_out[ARRSIZE];

memset( arr_in, '\0', ARRSIZE );
memset( arr_out, '\0', ARRSIZE );

Or just:

char arr_in[ARRSIZE] = {0};
char arr_out[ARRSIZE] = {0};

which saves you two memset calls.

Well, it appears to. But in a typical implementation, when auto
objects are on the stack, the arrays would have to be zeroed out at
runtime anyway. My own implementation actually generates a call to
memset to accomplish this. So the effect is probably the same, both
in behavior and performance. And one could argue that it is
stylistically preferable to make the memset call explicit, since it
avoids camouflaging a potentially expensive operation.

[snip]

>{
char* pc;

pc = arr_out;

while( (*arr_out++ = *arr_in++) ) ;

return pc;
}

How is this *your* implementation? It isn't significantly different from
the implementation on p105 of K&R2, with names changed to protect the
innocent and a return value added to get a closer match to ISO strcpy.

It's hardly necessary to make veiled accusations of plagiarism for
such a trivial piece of code. I suspect if you put 100 C programmers
in clean rooms and asked them to write an implementation of strcpy,
you'd only get about three essentially different versions, and this is
one of them. K&R is probably the most memorable appearance of the
`*p++ = *q++' idiom, but just because one saw it there and continues
to use it doesn't make one a plagiarist. It's a textbook, after all.

[Richard]

Nate Eldredge <na**@vulcan.la nwrites:

Richard Heathfield <rj*@see.sig.in validwrites:

>arnuld said:

>>I have created my own implementation of strcpy library function. I would
like to have comments for improvements:

[...]

>>>
int main( int argc, char** argv )
{
char* pc;

char arr_in[ARRSIZE];
char arr_out[ARRSIZE];

memset( arr_in, '\0', ARRSIZE );
memset( arr_out, '\0', ARRSIZE );

Or just:

char arr_in[ARRSIZE] = {0};
char arr_out[ARRSIZE] = {0};

which saves you two memset calls.

Well, it appears to. But in a typical implementation, when auto
objects are on the stack, the arrays would have to be zeroed out at
runtime anyway. My own implementation actually generates a call to
memset to accomplish this. So the effect is probably the same, both
in behavior and performance. And one could argue that it is
stylistically preferable to make the memset call explicit, since it
avoids camouflaging a potentially expensive operation.

You think

> char arr_in[ARRSIZE] = {0};

camouflages it? To be honest after spending time in c.l.c I get the
heebygeebies whenever I see memset with arrays - I'm not really sure
whats a character anymore, whats an array etc. I wonder if that memory
has "alignment issues" with "special pointers" etc etc. I used to think
of them as blocks of memory and all my programs just worked. c.l.c put
paid to that... :-;

>
[snip]

>>{
char* pc;

pc = arr_out;

while( (*arr_out++ = *arr_in++) ) ;

return pc;
}

How is this *your* implementation? It isn't significantly different from
the implementation on p105 of K&R2, with names changed to protect the
innocent and a return value added to get a closer match to ISO strcpy.

It's hardly necessary to make veiled accusations of plagiarism for
such a trivial piece of code. I suspect if you put 100 C programmers
in clean rooms and asked them to write an implementation of strcpy,
you'd only get about three essentially different versions, and this is
one of them. K&R is probably the most memorable appearance of the
`*p++ = *q++' idiom, but just because one saw it there and continues
to use it doesn't make one a plagiarist. It's a textbook, after all.

You would be amazed at how few would actually do it this way. There are
many people out there who discourage such stuff. I even read here once
that it "misuses C" ... the mind boggles. I have seen many code bases
where you hardly ever see a pointer used in its natural habitat. A
crying shame IMO.

[Keith Thompson]

Nate Eldredge <na**@vulcan.la nwrites:
[...]

Well, it appears to. But in a typical implementation, when auto
objects are on the stack, the arrays would have to be zeroed out at
runtime anyway. My own implementation actually generates a call to
memset to accomplish this. So the effect is probably the same, both
in behavior and performance. And one could argue that it is
stylistically preferable to make the memset call explicit, since it
avoids camouflaging a potentially expensive operation.

[...]

Why do auto arrays have to be zeroed? There's certainly no C
requirement for this; any such requirement would have to be
system-specific.

Of course an implementation is certainly allowed to zero auto objects.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[vippstar]

On Sep 8, 7:47 pm, Nate Eldredge <[e-mail] nwrote:

Richard Heathfield <[e-mail].i nvalidwrites:

arnuld said:

char arr_in[ARRSIZE];
char arr_out[ARRSIZE];

memset( arr_in, '\0', ARRSIZE );
memset( arr_out, '\0', ARRSIZE );

Or just:

char arr_in[ARRSIZE] = {0};
char arr_out[ARRSIZE] = {0};

which saves you two memset calls.

Well, it appears to. But in a typical implementation, when auto
objects are on the stack, the arrays would have to be zeroed out at
runtime anyway. My own implementation actually generates a call to
memset to accomplish this. So the effect is probably the same, both
in behavior and performance. And one could argue that it is
stylistically preferable to make the memset call explicit, since it
avoids camouflaging a potentially expensive operation.

Nonsense. memset sets the bit pattern to 0. {0} Sets pointers to NULL,
floating point objects to 0.0, integers to 0, etc.
They are not equivalent.

[Richard Heathfield]

Nate Eldredge said:

Richard Heathfield <rj*@see.sig.in validwrites:

>arnuld said:

<snip>

>>>
char arr_in[ARRSIZE];
char arr_out[ARRSIZE];

memset( arr_in, '\0', ARRSIZE );
memset( arr_out, '\0', ARRSIZE );

Or just:

char arr_in[ARRSIZE] = {0};
char arr_out[ARRSIZE] = {0};

which saves you two memset calls.

Well, it appears to. But in a typical implementation, when auto
objects are on the stack, the arrays would have to be zeroed out at
runtime anyway.

Fine, but that's the implementation' s problem. The saving is in the source
code: economy of expression.

My own implementation actually generates a call to
memset to accomplish this. So the effect is probably the same, both
in behavior and performance. And one could argue that it is
stylistically preferable to make the memset call explicit, since it
avoids camouflaging a potentially expensive operation.

It isn't very good camouflage, though, since any experienced C programmer
will recognise it for what it is. It's just a more elegant way to write
the code. We don't write char foo[8] = { 'H', 'e', 'l', 'l', 'o', '\0',
'\0', '\0' } just because it makes explicit the fact that eight characters
are being copied into the array. We write char foo[8] = "Hello", and trust
that competent programmers will understand.

>
[snip]

>>{
char* pc;

pc = arr_out;

while( (*arr_out++ = *arr_in++) ) ;

return pc;
}

How is this *your* implementation? It isn't significantly different from
the implementation on p105 of K&R2, with names changed to protect the
innocent and a return value added to get a closer match to ISO strcpy.

It's hardly necessary to make veiled accusations of plagiarism for
such a trivial piece of code.

I don't think it would be reasonable to call it plagiarism, since it's
blindingly obvious to all concerned that it's basically the K&R2 code. I
was just pointing out that "my own implementation" wasn't really the right
way to describe it.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999