[FFmpeg-devel] lavfi/buffersink: cast to uint64_t before shifting.

Fix CID 1466666.

Signed-off-by: Nicolas George <george@nsup.org>
---
 libavfilter/buffersink.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Nicolas George:
> Fix CID 1466666.
> 
> Signed-off-by: Nicolas George <george@nsup.org>
> ---
>  libavfilter/buffersink.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
> index 9338969bf1..58848941d4 100644
> --- a/libavfilter/buffersink.c
> +++ b/libavfilter/buffersink.c
> @@ -72,10 +72,10 @@ static void cleanup_redundant_layouts(AVFilterContext *ctx)
>  
>      for (i = 0; i < nb_counts; i++)
>          if (buf->channel_counts[i] < 64)
> -            counts |= 1 << buf->channel_counts[i];
> +            counts |= (uint64_t)1 << buf->channel_counts[i];
>      for (i = lc = 0; i < nb_layouts; i++) {
>          n = av_get_channel_layout_nb_channels(buf->channel_layouts[i]);
> -        if (n < 64 && (counts & (1 << n)))
> +        if (n < 64 && (counts & ((uint64_t)1 << n)))
>              av_log(ctx, AV_LOG_WARNING,
>                     "Removing channel layout 0x%"PRIx64", redundant with %d channels\n",
>                     buf->channel_layouts[i], n);
> 
Using ULL would be shorter.

- Andreas

Andreas Rheinhardt (12020-09-08):
> Using ULL would be shorter.

But it would be wrong, it could be more than 64 bits. For modern C,
using longs and shorts directly is a mistake (or the consequence of
dealing with an obsolescent library), these types are used internally to
implement the sane types from stdint.h. I know we use ULL like this all
over the place, but I will not use it in my code.

Regards,

On 9/8/2020 3:19 PM, Nicolas George wrote:
> Andreas Rheinhardt (12020-09-08):
>> Using ULL would be shorter.
> 
> But it would be wrong, it could be more than 64 bits. For modern C,
> using longs and shorts directly is a mistake (or the consequence of
> dealing with an obsolescent library), these types are used internally to
> implement the sane types from stdint.h. I know we use ULL like this all
> over the place, but I will not use it in my code.

You should use the stdint.h UINT64_C macro then, instead of casting.

> 
> Regards,
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

James Almer (12020-09-08):
> You should use the stdint.h UINT64_C macro then, instead of casting.

I probably *could*. But I find casting more readable. What benefit do
you see to them compared to casting?

Regards,

James Almer (12020-09-08):
> It's a macro designed for this specific purpose. Figured it would be
> proper, and we're using them in other parts of the code to shift the
> values by more than 32 bits, like you're doing here. But yes, i should
> have said could, not should.
> 
> I don't consider it less readable, and it's just as long as using a
> cast, but of course it's up to you.

I honestly do not know what good these macros do, except for sparking
bikeshedding discussions like this one. I can only assume they were
meant for barely-complying compilers where the cast would produce an
annoying false-positive warning.

Anyway, I pushed like this.

Thanks for your input.

Regards,