[FFmpeg-devel] [PATCH 1/7] avutil: add FF_BAIL_ON_OVERFLOW
Andreas Cadhalpun
andreas.cadhalpun at googlemail.com
Wed Dec 21 02:43:46 EET 2016
On 20.12.2016 15:22, wm4 wrote:
> On Mon, 19 Dec 2016 23:36:11 +0100
> Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
>
>> On 16.12.2016 17:22, wm4 wrote:
>>> On Fri, 16 Dec 2016 03:32:07 +0100
>>> Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
>>>
>>>> Suggested-by: Rodger Combs <rodger.combs at gmail.com>
>>>> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun at googlemail.com>
>>>> ---
>>>> libavutil/common.h | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/libavutil/common.h b/libavutil/common.h
>>>> index 8142b31..00b7504 100644
>>>> --- a/libavutil/common.h
>>>> +++ b/libavutil/common.h
>>>> @@ -99,6 +99,8 @@
>>>> #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
>>>> #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
>>>>
>>>> +#define FF_BAIL_ON_OVERFLOW(ctx, x) if (x) {av_log(ctx, AV_LOG_ERROR, "Overflow check failed: " #x"\n"); return AVERROR_INVALIDDATA;}
>>>> +
>>>> /* misc math functions */
>>>>
>>>> #ifdef HAVE_AV_CONFIG_H
>>>
>>> Are you sure we need the message?
>>
>> Yes, since such an overflow could just be a sign of a limitation in our
>> framework (think of bit_rate being int32_t) and does not necessarily mean
>> that the sample is invalid.
>>
>>> It's quite ugly.
>>
>> Do you have any suggestions for improving it?
>
> I'm pretty much against such macros for rather specific use-cases, and
> putting them into a public headers.
It is added to an "internal and external API header".
Feel free to send patches separating it into an internal and a public header.
> I'm thinking it'd be better to actually provide overflow-checking primitives,
Why?
> and I also don't think every overflow has to be logged.
I disagree for the reason I mentioned above.
Best regards,
Andreas
More information about the ffmpeg-devel
mailing list