> On Apr 11, 2025, at 16:36, Nicolas George <geo...@nsup.org> wrote:
>
> Zhao Zhili (HE12025-04-11):
>> From: Zhao Zhili <zhiliz...@tencent.com>
>>
>> The macro is meant to suppress false uninitialized warnings. However,
>> sometimes these 'false uninitialized warnings' are really undefined
>> behavior, and leading to real issue like crash, e.g., ab792634197e.
>>
>> For false uninitialized warnings, it can be silenced by initialization,
>> and compiler can easily optimize away unnecessary initializations.
>>
>> av_uninit shouldn't be used in any case.
>
> NAK, you are hiding the UBs, not fixing the bugs.
>
> If the author of the code put av_uninit, that means they believe the
> value will always have been initialized by the part of the code
> responsible for it. If that is not true, then it is a bug that can lead
> to an exploitable security issue or a silent data corruption.
>
> With your changes, nothing proves that the = 0 you put there is the
> right value, the bug is still there: the code expects the value to be
> correctly set, but instead there is an arbitrary 0.
>
> At least, with av_uninit, valgrind and fuzzing can find the bugs.
With UB, the compiler can remove branch check and assign some random
value to it, which cannot be detected by valgrind.
For ab792634197e, the UB is there for decades and never detected by
valgrind, and the warning is silenced by av_uninit.
>
> Regards,
>
> --
> Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
