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