On 04/12/2011 05:45 PM, Luca Barbato wrote: > On 4/12/11 5:30 PM, Max Horn wrote: > >> It's just that it feels a bit unfair to be upheld to standards that >> seem a much >> higher than what a lot of the existing code meets... > > Polishing is something we are trying to do little by little (or when > something is spotted). We try not to add more of such frail code if > possible. You are right, we should fix. > >> I mean, it took me about 2 minutes to come to find a piece of code in >> libav >> that has worse security issues than my patch ever had... Hum... > > ^^; > >> >> Anyway, I absolutely do see your point about not knowingly introducing >> new potentially >> problematic code -- which is why I didn't hesitate to address it with >> my updated patch. :) > > Great =) > >> >> And I would happily write a patch for riff.c and ff_get_wav_header in. >> Unfortunately, >> ff_get_wav_header has no way to signal an error to the caller. > >> So that leaves the options of inserting (the equivalent of) an >> assert(); or to change the >> signature of ff_get_wav_header, e.g. by adding a return value that can >> be used to signal >> an error. In the latter case, all calling code (seven demuxers, > including xwma) >> would have to be adjusted, too. > > I'm afraid that's the right thing to do. > >> I perfectly understand that multiple people on this project may have >> to review a patch >> before it gets accepted. And that it can take some days or longer, >> too. So I'll just wait. > > We try to be as quick as possible, sometimes we might take a bit more > sometimes we are too quick. Rule of thumb should be to wait about a day > or a night before pushing a queued up patch.
Both patches are scheduled to get pushed this night btw. -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
