On 11/06/17 16:12, Timo Rothenpieler wrote:
>> Seems dubious? That is not a small structure, and it's being used
>> essentially write-only here to skip over an unwanted part of the slice
>> header - since it will only ever write to a small proportion of the
>> elements, initialising all of them to zero feels like a waste.
>>
>> (The only argument in Coverity seems to be that passing a pointer to an
>> uninitialised structure to an external function is bad - it hasn't actually
>> looked at the function to observe that it doesn't read anything currently in
>> the structure.)
>
> It calls ff_h264_pred_weight_table in line 204, which it does analyze, and
> which accesses pwt->chroma_log2_weight_denom, which was not initialized
> before.
I think those accesses are wrong and should be fixed - patch following.
(I could believe that the monochrome H.264 stream with prediction weights
required to make this actually error out with the current code is quite rare.)
> I don't think doing = { 0 }; is expensive. iirc all elements except for the
> first one are zero-initialized already, even though it's
> implementation-defined or even undefined.
It's all indeterminate - see C11 section 6.7.9. A compiler could in theory
choose to initialise it to zero or 42 or any other value, but there is no
reason for any particular choice so it won't bother.
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
