On Mon, Oct 29, 2018 at 01:28:02PM -0700, Rick Moen wrote:
> Quoting Daniel Taylor (random@???):
>
> > They do, but that's not an excuse for using strcpy().
> >
> > Which they did.
>
> Of course, obviously. You _are_ aware I was merely trying to help by
> pointing out that strncpy (etc.) is suboptimal, right?

Well, it is possible to use strcpy() right. On the other hand, _every_ use
of strncpy() for a C string is a bug.

There are three possibilities:
A> either the string does overflow
B> or it doesn't
C> you know the string's length beforehand

If A>, then you have a nasty non-terminated string that can't be passed to
any function expecting a C string (resulting in a read overflow). Yay a
security hole, crash, or at least corrupted data.

If B>, you waste time clearing the buffer. As there's a static size
(otherwide it'd be C>), there's a good deal of headway. In a typical case
(judging from programs I looked at) you have a string of twelve bytes in a
buffer of 2K... and a clear every single copy. Yay significant slowdown.

If C>, you should have used memcpy() instead. Scanning for a 0 is slower
than a blind loop.

On the other hand, snprintf(), strlcpy() and so on do what naive intuition
says strncpy() would do.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came
⠈⠳⣄⠀⠀⠀⠀ together with silk (judging by today's amber stalls).