Le 29/10/2018 à 22:42, Adam Borowski a écrit :
> 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.


    Let's assume "the programmer knows what she is doing" (this is how
the C language assume its insecurity). Then she knows the length of the
destination is smaller than the length of the source. It is an error,
but, in some cases (which we are dealing with here), it is acceptable to
just truncate the string. So what can she do?

    Certainly strcpy() is unusable because it would overflow. The
fastest way to do the job with the standard C library is to invoke
strncpy() with sizeof(dest)-1 and append a null. The two other methods
are to use snprintf() or to copy the bytes one by one in a loop.

    Didier