Diego Biurrun <di...@biurrun.de> writes:
> On Sat, Sep 08, 2012 at 12:23:12AM +0100, Måns Rullgård wrote:
>> Alex Converse <alex.conve...@gmail.com> writes:
>> > On Fri, Sep 7, 2012 at 3:09 PM, Måns Rullgård <m...@mansr.com> wrote:
>> >> Alex Converse <alex.conve...@gmail.com> writes:
>> >>> On Fri, Sep 7, 2012 at 2:55 PM, Måns Rullgård <m...@mansr.com> wrote:
>> >>>> Alex Converse <alex.conve...@gmail.com> writes:
>> >>>>> On Fri, Sep 7, 2012 at 2:45 PM, Måns Rullgård <m...@mansr.com> wrote:
>> >>>>>> Alex Converse <alex.conve...@gmail.com> writes:
>> >>>>>>> Avoid writing the trailing NUL byte for id3v1 tags if length reaches
>> >>>>>>> max length.
>> >>>>>>>
>> >>>>>>> Based on an idea by: Michael Niedermayer <michae...@gmx.at>
>> >>>>>>>
>> >>>>>>> --- a/libavformat/mp3enc.c
>> >>>>>>> +++ b/libavformat/mp3enc.c
>> >>>>>>> @@ -37,8 +37,10 @@ static int id3v1_set_string(AVFormatContext *s,
>> >>>>>>> const char *key,
>> >>>>>>> uint8_t *buf, int buf_size)
>> >>>>>>> {
>> >>>>>>> AVDictionaryEntry *tag;
>> >>>>>>> - if ((tag = av_dict_get(s->metadata, key, NULL, 0)))
>> >>>>>>> - av_strlcpy(buf, tag->value, buf_size);
>> >>>>>>> + if ((tag = av_dict_get(s->metadata, key, NULL, 0))) {
>> >>>>>>> + buf_size = FFMIN(buf_size, strlen(tag->value));
>> >>>>>>> + memcpy(buf, tag->value, buf_size);
>> >>>>>>> + }
>> >>>>>>> return !!tag;
>> >>>>>>> }
>> >>>>>>
>> >>>>>> Or even simpler, use strncpy() and drop the initial memset().
>> >>>>>
>> >>>>> That won't compile,
>> >>>>
>> >>>> Why not?
>> >>>
>> >>> error: implicit declaration of function
>> >>> ‘strncpy_is_forbidden_due_to_security_issues_use_av_strlcpy’
>> >>
>> >> So drop that nonsense. There is nothing more ridiculous than elaborate
>> >> workarounds for self-imposed rules.
>> >
>> > That fixed actual buffer overflows. If developers here were capable of
>> > using strncpy() properly we wouldn't have had to ban it. The effects
>>
>> Spare the condescending tone, please. You were the one who did the bad
>> fix.
>>
>> > of using strlcpy() where strncpy() is a better fit tend to be much
>> > more innocuous (as seen here).
>>
>> That is no reason to refuse using the best tool for the job.
>
> Let's skip the pointless exchange of pleasantries and get the job done
> instead. Justin, could you please decide which of the two alternatives
> is to be the way (TM) to resolve the issue at hand and put an end to
> the bickering?
It is not pointless. Alex is suggesting a blanket ban on certain
standard features because it's possible to use them incorrectly. Guess
what, *everything* can be used incorrectly. Reduced to the biggest
idiot subsets of languages belong in moronic companies staffed by
trained monkeys. Is that what we want libav to look like?
--
Måns Rullgård
m...@mansr.com
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
