[FFmpeg-devel] [PATCH] forbid strcpy

Måns Rullgård mans
Sat Jan 30 20:42:49 CET 2010


Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Sat, Jan 30, 2010 at 02:10:00PM -0500, Ronald S. Bultje wrote:
>> On Jan 30, 2010, at 12:59 PM, Reimar D?ffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> >On Sat, Jan 30, 2010 at 11:02:34AM -0500, Ronald S. Bultje wrote:
>> >>
>> >>On Jan 30, 2010, at 10:34 AM, Reimar D?ffinger
>> >><Reimar.Doeffinger at gmx.de> wrote:
>> >>>this will cause a lot of build failures, so can't be applied as
>> >>>is, but
>> >>>please all maintainers: either remove any strcpy uses from your
>> >>>copy or
>> >>>complain now, or I take the freedom to modify your code without
>> >>>asking.
>> >>
>> >>This is not ok, strcpy() is fine and faster in a lot of places where
>> >>we copy between internal buffers. There is nothing wrong with that.
>> >
>> >Please show me a single use where we'd notice if it was 20 times
>> >faster.
>> >I find it unlikely that there are cases where speed matters and
>> >strcpy would be acceptable, it certainly is not particularly fast.
>> 
>> I agree it won't make much of a difference, just expressing my
>> feeling that we're entering a gray area.
>
> My feeling is that it is more likely to show people that they implemented
> something suboptimally.
> Upon reviewing strncpy uses in contrast I found that the usage in
> strncpy actually is quite valid and I couldn't think of a really
> good way to avoid it.

Using strncpy is usually wrong and mostly useless.  If the destination
is too small, it doesn't null terminate, but insists on filling up any
extra space with zeros.  I can't think of any situation where strlcpy
isn't a better choice.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list