On Thu, 2011-12-22 at 11:52 +0000, Måns Rullgård wrote: > Tomas Härdin <[email protected]> writes: > > > On Wed, 2011-12-21 at 17:56 +0100, Janne Grunau wrote: > >> On 2011-12-21 15:47:24 +0100, Tomas Härdin wrote: > >> > On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote: > >> > > On 21/12/11 14:58, Tomas Härdin wrote: > >> > > > I hope you made sure the code still work fine on 32-bit systems, > >> > > > especially when entry counts are ~10^9. > >> > > > >> > > Do you have a sample for that? > >> > > >> > FATE sample with a single bit flipped at 0x1e9d, turning the zero-entry > >> > index entry into a 1 Gi entry one: > >> > http://titan.codemill.se/~tomhar/samples/C0023S01-ohnoes.mxf > >> > >> Thanks for noticing. I hope such index size are invalid as in this > >> example. > > > > Why would they be? The spec certainly doesn't imply any such thing - > > neither should the demuxer. > > > >> Since I'm not really sure what a good limit on the number > >> of index entries is, I've added checks against overflowing INT_MAX > >> even on 64-bit. > > > > Why not simply keep av_calloc()? It already does such a check. > > It does not allow you to distinguish between a crazy size and an out of > memory error for a modest size. Values read from the file should be > validated by the demuxer as a matter of principle.
While I agree that validation is important, placing arbitrary limits is likely to cause more headache in this case. It's also hard to define "crazy" when it comes to MXF. After all, we're talking about a format that allows indexing individual scanlines in raw footage.. /Tomas _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
