[FFmpeg-devel] [PATCH] mem: prefer SIZE_MAX over INT_MAX in av_malloc() and av_realloc() checks

[Michael Niedermayer]

On Thu, May 19, 2011 at 10:53:12AM +0200, Reimar Döffinger wrote:
> On 19 May 2011, at 09:00, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
> > On date Thursday 2011-05-19 08:20:11 +0200, Reimar Döffinger encoded:
> >> On 19 May 2011, at 06:08, Michael Niedermayer <michaelni at gmx.at> wrote:
> >>> On Thu, May 19, 2011 at 12:07:27AM +0200, Stefano Sabatini wrote:
> >>>> Now the functions accepts size_t size rather than int values, so using
> >>>> size_t is more correct.
> >>> 
> >>> 2gb should be enough for everyone ;)
> >>> seriously i think allocating more (currently) is likely a bug
> >>> maybe in a few years rawvideo frames will need but until then its
> >>> safer to not extend this limit
> >>> thats IMHO
> >> 
> >> I agree. I also prefer for behaviour to differ as little as possible between 32 and 64 bit systems.
> > 
> > buffers are used not only for frames, check #185.
> 
> Well, but that case is rather an argument for an even smaller value.
> Since FFmpeg does not implement a cache, there shouldn't be any/many valid allocations significantly larger than the raw frame size.
> 
> > Also MAX_INT is not fixed as well, if you want to avoid 32/64-bit
> > system difference you should rather use a define (FF_MAX_MALLOC_SIZE).
> 
> In reality INT_MAX is the same for all relevant systems.

> But otherwise I would even consider a runtime-settable max. allocation size an interesting feature.

yes


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110519/6cccfd7a/attachment.asc>