Re: strcpy: a niche function you don't need

Mark Potts
Message ID
DKIM signature
Download raw message
Sad read. Completely misunderstands the issues. Similar to pleas to
rewrite everything in "memory safe" languages. Avoiding functions such
as strcpy simply moves the goalposts. If you can't write robust and
bug-free software using such techniques you won't be able to write it in
other languages or idioms no matter how "safe" they claim to be. Strive
to thoroughly understand the behavior and limitations of the constructs
you are using and you will become a proficient programmer able to
develop robust and bug-free software. Blaming perfectly serviceable
functions such as strcpy just diverts attention from the need for
professional competence.

Reminds me of the old network software trope "Be liberal in what you
accept, and conservative in what you send." which resulted in a
generation of ill-defined network protocols and implementations that
haunts us to this day ("well it worked on ...").

Still, with many current software developers trained on Stack Overflow
(aka "blind leading the blind") I shouldn't be surprised.

Don't get me started!

Re: strcpy: a niche function you don't need

Message ID
<bb8953f8-875c-371d-13e8-0d42ec4e55da@mail.com> (view parent)
DKIM signature
Download raw message
I don't think you understood my article since I agree with you about such 
pleas and professional competence. I'm not talking about safety beyond 
simple correctness. Anywhere you might use strcpy() (or strlcpy(), etc.) 
it makes more sense to use memcpy(). If you can't drop memcpy() in its 
place then you're not using strcpy() correctly. I've never seen a 
legitimate use case for strcpy() (or strlcpy(), etc.), and I'm speaking 
strictly from a perspective of correctness and efficiency — qualities I 
believe are more important than safety.
Reply to thread Export thread (mbox)