Tom said:
While I agree blanket "never use X" statements are nonsense, for
example, there are plenty of good uses for goto, strcpy is one that
just should be avoided.
It's the sort of bad habits that lead to other things like
- not checking parameters for validity
- not checking returns of malloc/calloc
- Not checking boundaries
Using strcpy() is the cause of these bad habits? Can you
quote any research to support this claim, or is it just one of
those "Stop, or you'll go blind" things?
The act of calling strcpy(), or even the intent thereof,
does not prompt me to swallow untrusted values from untrusted
sources. Nor does it influence me to omit tests for malloc()
failure. I *do* omit boundary checking, because there's no
need: I allocate sufficient space before copying, and once
the space is known to suffice there's no reason to check it.
How often does "malloc" really fail? So I guess checking the return
is just paranoia, etc. Sometimes not being lazy up front saves having
to go back and fix things later when it costs more to re-open the
code.
If this has anything at all to do with strcpy(), I am
unable to discern the connection.
As for never having a use for making a copy, sometimes you're
transferring it from one structure to another and you're not at a
point to know where the pointers came from [stack, heap, auto, ???] so
you can't just copy the pointer.
Yes, I know -- and I *did* say that copying is sometimes
necessary. Often you want a copy as an "initializer" for an
object you will then proceed to modify, but you'd like the
original to remain intact. Sometimes the original is itself
in jeopardy, sitting in a soon-to-vanish auto array or in a
soon-to-be-overwritten I/O buffer. And sometimes the point
of copying isn't to create redundant data but to rearrange,
as in sorting an array.
... and when a string is the thing you want to copy,
strcpy() is just the ticket.