[FFmpeg-devel] [PATCH] *alloc(type)

[Ronald S. Bultje]

Hi guys,

On Sat, Nov 20, 2010 at 10:53 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sat, Nov 20, 2010 at 02:20:08PM +0100, Reimar D?ffinger wrote:
>> On Sat, Nov 20, 2010 at 04:05:32PM +0300, Yuriy Kaminskiy wrote:
>> > Reimar D?ffinger wrote:
>> > > On Sat, Nov 20, 2010 at 04:37:30AM +0100, Michael Niedermayer wrote:
>> > >> patchset below fixes the type used in malloc and co
>> > >> The sense behind this patch is that feeding things that dont fit in unsigned
>> > >> int into *alloc() can lead to successfull allocation of too small arrays which
>> > >> is pretty bad.
>> > >> There are probably more functions that should be changed like av_new_packet()
>> > >> but i had to start somewhere and will look into the others too if noone else
>> > >> does.
>> > >> Note, i will apply this in a few days if there are no objections
>> > >
>> > > This has some side-effects I do not like.
>> > > For example, allocating more than 4 GB now becomes possible, even
>> > > though such an allocation is almost certain to be a bug.
>> > No. A bit more context:
>> > === cut ===
>> > void *av_malloc(unsigned int size)
>> > {
>> > ? ? void *ptr = NULL;
>> > #if CONFIG_MEMALIGN_HACK
>> > ? ? long diff;
>> > #endif
>> >
>> > ? ? /* let's disallow possible ambiguous cases */
>> > ? ? if(size > (INT_MAX-16) )
>> > ? ? ? ? return NULL;
>>
>> Ok, I'll change my suggestions to:
>> How about using uint64_t always?
>
> i dont know, it would slow down pure 32bit systems

Not just that, any malloc implementation doesn't allow 64-bit
allocations on 32-bit systems anyway (theory or practice), so we're
essentially lying and complicating the situation for 32-bit systems
for no good reason. At least for size_t on 64-bit you could claim that
the potential future benefit of 64-bit allocations makes it worth it.

My question (for all suggested changes): what specific bug does this change fix?

Ronald