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.
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
