strcpy - my implementation

[Richard Heathfield]

Re: strcpy - my implementation

CBFalconer said:

Keith Thompson wrote:

>>

... snip ...

>>
>For example, if I'm examining the value of a character, the
>following are equivalent:
> if (c) { ... }
> if (c != '\0') { ... }
>I prefer to write the latter, because the value of c by itself
>isn't just a true or false value, but the result of the "!="
>operator is.

>
I disagree.

With what? With Keith's claim to prefer one style over the other? If so,
what makes you think you know better than he does which style he prefers?
Or are you disagreeing with his claim that the value of c by itself isn't
just a true or false value? If so, please explain why it isn't also a
numeric value.

The (c) expression worries only about whether the
character is or is not something with a zero value.

What has that to do with what he said? Here, you are not disagreeing with
something he said, but with something he did not say.

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

[Anand Hariharan]

Re: strcpy - my implementation

On Mon, 08 Sep 2008 10:54:02 +0000, Sjoerd <sjoerder@gmail .comwrote:

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.

While you correctly identified the statements as initialisation, I
suspect you are confusing initialisation with assignment.

Note that the RHS is {0}, not 0.

Finally, if an array is defined as "int a[ARRSIZE];", then "a[ARRSIZE]"
is NOT an element of the array 'a'.

- Anand

[arnuld]

Re: strcpy - my implementation

On Mon, 08 Sep 2008 17:48:20 +0000, Richard Heathfield wrote:

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.

No, it is not. That I learned from Stroustrup, section 6.2.5, special
edition. I do not even remember that I ever saw that code ever in K&R2.




--

https://www.lispmachine.wordpress.com

my email is @ the above blog.
Google Groups is Blocked. Reason: Excessive Spamming

[arnuld]

Re: strcpy - my implementation

On Mon, 08 Sep 2008 17:48:20 +0000, Richard Heathfield wrote:

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]

That whole discussion leaves me wondering whether:

char arrc[100] = {0};

is same as:

char arrc[100];
memset(arrc, '\0', 100);

or whether latter is more expansive than former ? and which one is
advised to use by c.l.c ?





--

https://www.lispmachine.wordpress.com

my email is @ the above blog.
Google Groups is Blocked. Reason: Excessive Spamming

[arnuld]

Re: strcpy - my implementation

On Mon, 08 Sep 2008 19:08:08 +0200, Richard wrote:

>Nate Eldredge <nate@vulcan.la nwrites:
>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.

I am not a native English man so I don't know what you mean by "....used
in its natural habitat..."

Do you want to say that c.l.c discourages *p++ = *q++ ?




--

https://www.lispmachine.wordpress.com

my email is @ the above blog.
Google Groups is Blocked. Reason: Excessive Spamming

[arnuld]

Re: strcpy - my implementation

On Mon, 08 Sep 2008 11:51:45 +0500, arnuld wrote:

Here is the new version whihc puts a check on maximum input:


/* My version of "strcpy - a C Library Function
*
* version 1.1
*
*/

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

enum { ARRSIZE = 4 };

char* my_strcpy( char*, char* );

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

char src[ARRSIZE+1] = {0};
char dest[ARRSIZE+1] = {0};


if( 2 != argc )
{
perror("USAGE: ./exec \" your input \"\n");
exit( EXIT_FAILURE );
}
else
{
input_size = strlen( argv[1] );

if( ARRSIZE < input_size )
{
fprintf(stderr, "Input must be %d characters or less\n", ARRSIZE);
exit(EXIT_FAILU RE);
}

strcpy( src , argv[1] );
}

pc = my_strcpy( dest, src );


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


return EXIT_SUCCESS;
}



char* my_strcpy( char* dest, char* src )
{
char *const pc = dest;

while( (*dest++ = *src++) )
{
;
}

return pc;
}




The one thing I do not understand here, if the arrays are created with
size ARRSIZE or even ARRSIZE+1 ( +1 for extra NULL character), the output
is not affected. Since the user has to enter 4 characters in this case
like "Love" + 1 for NULL but even with ARSSIZe = 4 in totoal, it works
fine. Is there some problem here ?



--

https://www.lispmachine.wordpress.com

my email is @ the above blog.
Google Groups is Blocked. Reason: Excessive Spamming

[CBFalconer]

Re: strcpy - my implementation

arnuld wrote:

>

.... snip ...

>
That whole discussion leaves me wondering whether:
>
char arrc[100] = {0};
>
is same as:
>
char arrc[100];
memset(arrc, '\0', 100);
>
or whether latter is more expansive than former ? and which one
is advised to use by c.l.c ?

They are basically the same in code generated, although that is
obviously up to the decisions of the implementor. The advantage of
the two statement version is that you can separate the activity
from the sawing off of the memory space (barring use of const), and
the generated code is closer to what you actually typed. To me,
this adds understanding.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Ian Collins]

Re: strcpy - my implementation

arnuld wrote:

>On Mon, 08 Sep 2008 11:51:45 +0500, arnuld wrote:

>
Here is the new version whihc puts a check on maximum input:
>
>
>
char* my_strcpy( char* dest, char* src )
{

You still haven't fixed the const on the src parameter.


--
Ian Collins.

[Nick Keighley]

Re: strcpy - my implementation

On 9 Sep, 02:16, Keith Thompson <ks...@mib.orgw rote:

Richard<rgr...@ gmail.comwrites :

pete <pfil...@mindsp ring.comwrites:

>

Richard wrote:
>Richard Heathfield <r...@see.sig.i nvalidwrites:

>

>>CBFalconer said:

>

>>>pete wrote:
>>>>>arnuld said:
>>>... snip ...
>>>>>>  while( (*arr_out++ = *arr_in++) ) ;
>>>>/* I would go even further than just extra parentheses: */

>

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

>

>>>Silly and pointless.
>>I disagree. An explicit comparison against 0 is pointless in terms
>>of the code, yes, but it's not pointless in terms of
>>self-documentation, and it certainly isn't silly.

>

>I disagree. It is long winded and unnecessary. "while(*d++=*s+ +){}"is a
>corner stone of C programming and understanding. Adding the comparison
>does nothing to aid the understanding. A style thing maybe.

>

It is a style thing.
The one and only circumstance
under which I will ommit the explicit comparison against zero
(assuming that zero is what the expression is being compared against),
is when the expression is conceptually boolean in nature,
such as something like:

>

    while (isspace(*c)) {

>

Could you explain why C does not effectively make the while() above
"boolean" in nature and will not always do so?

>
It does, of course; that's not the point.
>
Since I share pete's opinion on this style issue, I'll try to explain.
>
When I write an if or while statement, I prefer to use an expression
that is *conceptually* boolean.  By "conceptual ly boolean", I mean
that the value of the expression can be thought of as either true or
false, and carries no additional information.
>
For example, if I'm examining the value of a character, the following
are equivalent:
    if (c) { ... }
    if (c != '\0') { ... }
I prefer to write the latter, because the value of c by itself isn't
just a true or false value, but the result of the "!=" operator is.
>
Similarly, I would write
    if (strcmp(s1, s2) != 0) { ... }
rather than
    if (!strcmp(s1, s2)) { ... }
>
and I would write
    if ((ptr = malloc(N)) != NULL) { ... }
rather than
    if (ptr = malloc(N)) { ... }
>
and so forth.
>
I'm perfectly well aware (as is pete, I'm sure) that in each case the
two forms are precisely equivalent, and will most likely result in
identical generated code.  I'm also aware that some C programmers
(including, if I'm not mistaken, Kernighan and Ritchie themselves)
prefer the terser forms and consider the forms that I prefer to be too
verbose.  I don't necessarily think that preference is wrong, I just
don't share it.  Finally, I don't have any real difficulty
understanding either form; it might sometimes take me a marginally
longer time to understand something in the shorter form, but it's not
really significant.

I use the same conventions for the same reasons

--
Nick Keighley

[Flash Gordon]

Re: strcpy - my implementation

CBFalconer wrote, On 09/09/08 05:39:

<snip>

However, notice that replacing strcpy is different than adding
strlcpy.

On some implementations it is the same.

strcpy exists in the current libraries. strlcpy does
not.

Apart from the implementations which provide it as an extension,
something they are allowed to do.

Any possible problem is somewhere in the future.

Apart from it being undefined behaviour and the fact that some
implementations do define it.

And, as I
pointed out, those names are alterable in the source code.

I agree with that. However they do not have anything to do with what the
OP was doing which was as an exercise re-implementing strcpy.
--
Flash Gordon

[Richard Heathfield]

Re: strcpy - my implementation

arnuld said:

>On Mon, 08 Sep 2008 17:48:20 +0000, Richard Heathfield wrote:

>
>

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

>
No, it is not. That I learned from Stroustrup, section 6.2.5, special
edition. I do not even remember that I ever saw that code ever in K&R2.

Nevertheless, it is still basically the K&R2 code. Where do you think
Stroustrup first saw 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

[Richard Heathfield]

Re: strcpy - my implementation

arnuld said:

>On Mon, 08 Sep 2008 17:48:20 +0000, Richard Heathfield wrote:

>
>

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

>
>
That whole discussion leaves me wondering whether:
>
char arrc[100] = {0};
>
is same as:
>
char arrc[100];
memset(arrc, '\0', 100);
>
or whether latter is more expansive than former ?

Since you're initialising an array of integers (for chars are integers),
they do the same thing. The first version does it in fewer lines of code.
If the type were non-integer (e.g. pointer, or floating point, or struct
or union of any kind), the two versions would not be equivalent and the
memset version would simply be wrong.

and which one is advised to use by c.l.c ?

That depends on which c.l.c. subscriber you ask, but I'd go for the version
that is right every time, wouldn't you?

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

[Old Wolf]

Re: strcpy - my implementation

On Sep 9, 5:34 pm, CBFalconer <cbfalco...@yah oo.comwrote:

Keith Thompson wrote:

    if (c) { ... }
    if (c != '\0') { ... }

>
I disagree. The (c) expression worries only about whether the
character is or is not something with a zero value.  The (c !=
'\0') expression expressly converts that zeroness into either the
value 0 or the value 1 before testing.  Optimization may affect
this.
>
I would normally expect the second expression to generate larger
code than does the first, with optimization disabled.

I don't know what you're smoking today, but
the above two if statements are exactly
equivalent in effect, and I challenge you
to come up with a compiler that generates
different code for them, let alone one that
actually causes a different code branch to
execute.

[Old Wolf]

Re: strcpy - my implementation

On Sep 9, 6:18 pm, arnuld <sunr...@invali d.addresswrote:

That whole discussion leaves me wondering whether:
>
   char arrc[100] = {0};
>
is same as:
>
   char arrc[100];
   memset(arrc, '\0', 100);
>
or whether latter is more expansive than former ?  and which one is
advised to use by c.l.c ?

They both have the same effect, but the first
one is far better because it is less error-prone.

Anyone who disagrees needs to notice that the
1970s have ended, IMHO.

Examples of memset errors:

http://www.google.com/codesearch?hl=en&lr=&q=memset\s*\(.%2B,\s*0\s*\)&btnG=Search

[pete]

Re: strcpy - my implementation

CBFalconer wrote:

I disagree. The (c) expression worries only about whether the
character is or is not something with a zero value. The (c !=
'\0') expression expressly converts that zeroness into either the
value 0 or the value 1 before testing. Optimization may affect
this.
>
I would normally expect the second expression to generate larger
code than does the first, with optimization disabled.

I expect
while (c)
to generate the exact same code as
while ((((((c) != 0) != 0) != 0) != 0) != 0)
with optimization disabled, regardless of the type of (c),
and regardless of whether (0) is replaced by ('\0').

--
pete