[x264-devel] Re: bug in x264_cqm_init ?

[Måns Rullgård]

Loren Merritt <lorenm at u.washington.edu> writes:

> On Thu, 3 May 2007, Fejes Dávid wrote:
>
>> Memory is never allocated for h->dequant8_mf, h->quant8_mf and
>> h->unquant8_mf.
>>
>> x264_cqm_init (in common/set.c) will upload this matrices with data,
>> but it doesn't allocates any memory before that for these pointers. In
>> my build it causes general protection fault (or simply it mess up
>> another variables). If I paste the corresponding x264_memalloc
>> function calls onto the beginning of the x264_cqm_init, it goes well.
>>
>> If I'm wrong, please let me know it. I've downloaded x264 at
>> 22.07.2007 from the trunk, excuse me if you have corrected this.
>
> Does this patch give an assert failure?
> If so, I'll have to rethink my assumptions about compilers. Though I
> don't see how to fix it without adding code complexity.
> If not, I can't see how else it would break.
>
> +    assert((void*)&h->  quant4_mf[4] == (void*)&h->  quant8_mf[0]);
> +    assert((void*)&h->dequant4_mf[4] == (void*)&h->dequant8_mf[0]);
> +    assert((void*)&h->unquant4_mf[4] == (void*)&h->unquant8_mf[0]);
> +    assert((void*)&h->quant4_bias[4] == (void*)&h->quant8_bias[0]);

There's no guarantee that those conditions are true.  The compiler is
allowed to add padding between any struct members.  If you need these
arrays to be contiguous you could declare them as a single array and
initialise two pointers into it.  That said, I'd be surprised if any
compiler actually added any padding here.

-- 
Måns Rullgård
mans at mansr.com

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html