check return value of strcpy()

[arnuld]

Is it pointless to check the return value of strcpy() (it will be
never be NUL anwyay). If yes, How can I be sure that contents are
successfully copied ?

 

[vippstar]

Is it pointless to check the return value of strcpy() (it will be
never be NUL anwyay). If yes,  How can I be sure that contents are
successfully copied ?

What is NUL? Take the time to type out your post properly.
You can be sure strcpy did what it must do if you do not invoke
undefined behavior.

 

[arnuld]

What is NUL? Take the time to type out your post properly.

Eh.. it as NULL

 

[Keith Thompson]

Is it pointless to check the return value of strcpy() (it will be
never be NUL anwyay). If yes, How can I be sure that contents are
successfully copied ?

(Quibble: you mean NULL, not NUL.)

Yes, checking the return value of strcpy() is pretty much pointless.
It always returns its first argument. I think having it return its
first argument is supposed to be convenient in some cases.

The way to make sure the contents are successfully copied is to make
sure, *before* you call it, that there's enough room in the
destination array to hold the source string, that you're able to write
to it, that the source string is properly terminated, and so forth.
There are no *detectable* errors that can occur during a call to
strcpy(). (Well, conceivably it could check for null arguments, but
it's not required to do so.)

 

[vippstar]

The way to make sure the contents are successfully copied is to make
sure, *before* you call it, that there's enough room in the
destination array to hold the source string, that you're able to write
to it, that the source string is properly terminated, and so forth.
There are no *detectable* errors that can occur during a call to
strcpy().  (Well, conceivably it could check for null arguments, but
it's not required to do so.)

char s[] = "42";
strcpy(s, s); seems to comply to your requirements, but it's UB.

 

[Keith Thompson]

The way to make sure the contents are successfully copied is to make
sure, *before* you call it, that there's enough room in the
destination array to hold the source string, that you're able to write
to it, that the source string is properly terminated, and so forth.
There are no *detectable* errors that can occur during a call to
strcpy().  (Well, conceivably it could check for null arguments, but
it's not required to do so.)

char s[] = "42";
strcpy(s, s); seems to comply to your requirements, but it's UB.

It fails to comply to the "and so forth" clause. I wasn't trying to
be complete.

 

[user923005]

Is it pointless to check the return value of strcpy() (it will be
never be NUL anwyay). If yes,  How can I be sure that contents are
successfully copied ?

The return value is useful because it is a function. Hence, you can
use the result in-line.

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

static char string[256];
int main(void)
{
puts(strcat(strcpy(string, "This is a "), "string."));
return 0;
}

OK, so this example is a little wacky. But there could conceivably be
some places where inline use would be useful.

 

[vippstar]

(e-mail address removed) writes:

[...]

char s[] = "42";
strcpy(s, s); seems to comply to your requirements, but it's UB.

It fails to comply to the "and so forth" clause.  I wasn't trying to
be complete.

I know (or at least I suspected) that you weren't trying to offer a
complete description, but does the OP know that too? Well, after this
chat he surely does.

 

[Hallvard B Furuseth]

user923005 said:
Returning a pointer to the null terminator would be even more
useful. With a function such as that (say, rntp_strcpy, to coin a
gerharsterly name), (...)

OpenBSD calls it strlcpy(), along with strlcat(). There have been
attempts to get them standardized, I don't know the status of that
effort.
http://www.gratisoft.us/todd/papers/strlcpy.html
http://www.openbsd.org/cgi-bin/man.cgi?query=strlcpy

 

[Martin Ambuhl]

Is it pointless to check the return value of strcpy() (it will be
never be NUL anwyay). If yes, How can I be sure that contents are
successfully copied ?

The return value of strcpy() is a convenience only, allowing the address
of the target to be an expression and the return value to be the result
of evaluating that expression. One might well say that the return value
of strcpy() exists only because other functions like strcat, strchr,
strerror(), strpbrk(), strrchr(), strstr() return pointers to char. All
str* functions return some kind of value, and for consistency strcpy()
also returns one. I don't think that any of these return values are
used to represent an error condition (although the null pointer from
strchr, strrchr, strstr might be interpreted as such), so "checking" the
return value is usually a meaningless term.

Please note that "NUL" is _not_ a null pointer. The name used for the
null pointer, assuming it defined, usually by an appropriate header, is
"NULL". "NUL" is used with some character sets, not necessarily the one
used by any particular C implementation, as a name for the '\0'
character. It is a perhaps trivial point and perhaps unfair, but
misusing names in this way is one of the things by which people judge
you. And, no matter how much you think other people's judgments
unimportant, they can matter.

 

[luserXtrog]

The return value of strcpy() is a convenience only, allowing the address
of the target to be an expression and the return value to be the result
of evaluating that expression.  One might well say that the return value
of strcpy() exists only because other functions like strcat, strchr,
strerror(), strpbrk(), strrchr(), strstr() return pointers to char.  All
str* functions return some kind of value, and for consistency strcpy()
also returns one.  I don't think that any of these return values are
used to represent an error condition (although the null pointer from
strchr, strrchr, strstr might be interpreted as such), so "checking" the
return value is usually a meaningless term.

Please note that "NUL" is _not_ a null pointer.  The name used for the
null pointer, assuming it defined, usually by an appropriate header, is
"NULL".  "NUL" is used with some character sets, not necessarily the one
  used by any particular C implementation, as a name for the '\0'
character.  It is a perhaps trivial point and perhaps unfair, but
misusing names in this way is one of the things by which people judge
you.  And, no matter how much you think other people's judgments
unimportant, they can matter.

This seems to be a detail which schlepps with it a certain inherent
potential for confusion. NUL and NULL do, in a sense, "mean the same
thing" but they are Categorically different. Amusingly, by coincidence
their textual representation mirrors those differences: NULL is bigger
than NUL. And NIL is smaller still (on a different axis of measure).
Were one to browse the ASCII table a few hundred times, this
correspondence might even be absorbed subliminally by the pattern that
control characters are ubiquitously described by 3-letter
abbreviations. NULL, by contrast exists in a world of 4-letter things:
char void *str.

 

[CBFalconer]

.... snip ...

OpenBSD calls it strlcpy(), along with strlcat(). There have been
attempts to get them standardized, I don't know the status of that
effort.
http://www.gratisoft.us/todd/papers/strlcpy.html
http://www.openbsd.org/cgi-bin/man.cgi?query=strlcpy

There is also another public domain version of the implementing
code, with some references back to the originals. See:

<http://cbfalconer.home.att.net/download/strlcpy.zip>

 

[Guest]

That code is horrible. You break basic rules about conditions and
expressions being on the same line making

whilst I don't put the condition and expression on the same line

it almost impossible to debug.

again, a RNN obsession

<snip>

 

[CBFalconer]

whilst I don't put the condition and expression on the same line
take note that the "basic rule" is Richard <noname>'s own invention

Richard the nameless is plonked here, as a troll. Note the useful
criticism mentioning "basic rules" without expressing them, or even
providing a reference to the C standard. BTW, the code has been
verified (and the checking code is included), so debuggery is not
needed. So the main point of this sub-thread is to demonstrate
that Richard the nameless can't read C code.

 

[Guest]

It IS a basic rule in the huge majority of places. If you think
otherwise then your experience is limited.



Yes most of the world who maintain other peoples code use them.

including me.

You
clearly know nothing about them as was apparent from your first comments
about how you thought they were used.

sorry, could you expand on that? What first comments?

I'd like to ask you a question.

You are asked to find a bug in a 200,000 line system. It happens 8 hours
into a run when certain rare conditions collide. You are not sure of the
conditions exactly.

....and the running system is 3000 miles away and they haven't given
you the
core dump.

How do YOU find it?

I might use a debugger. But the reference system is often very
different from
the field system. In fact half the reference system is in another
country.

I'll tell you how I find it. I run it in a debugger and do a backtrace
at the crash position. I then set certain watch points as it approaches
the crash time and examine how the state data is. It is then usually
trivial to track down. What do you do big guy? Print out 200,000 lines
of code and read it?

I'm glad you have such easy to debug systems to work on.

I have a feeling you might be as inefficient as I initially thought. I
had thought you might just be trolling. Now I'm not so sure.

Does it cross your mind that not everyone is working in the same
environment as you?

Or would you maybe put 2000 printfs in the code and then print out the
data and read that without the code in place?

Anything you can do with printf you can do more easily and with less risk
in a good debugger. Your reluctance to recognise that marks you as
stubborn bordering on incompetent in my opinion. Still, if it makes you
happy best of luck. You will always find certain c.l.c regs only too
willing to support the "old ways".

The only reason I pick on your "Use a debugger for everything"
posts if you give the impression that there is only one to do things
which is inflexible and wrong. I'm not against debuggers (despite your
frequent
misrepresentations of my position), I'm just agaisnt your mono-
chromatic
view of the world.


the sig seems appropriate

 

[Guest]

It seems you are only happy picking on noobs.

sorry Richard! I'd begun to stop thinking of you as a noob!