[FFmpeg-devel] [PATCH] Remove unsafe bitwise OR on FFVulkanExtensions enum

2022-07-08 Thread Amir Mazzarella
FFVulkanExtensions enum does not have a value for 0 defined, and bitwise OR on enums is not safe. The function returns uint64_t, so it makes more sense and is safer to do arithmetic in terms of uint64_t Signed-off-by: Amir Mazzarella --- libavutil/vulkan_loader.h | 4 ++-- 1 file changed, 2

[FFmpeg-devel] [PATCH] Make implicit void pointer cast explicit

2022-07-08 Thread Amir Mazzarella
Signed-off-by: Amir Mazzarella --- libavutil/vulkan_loader.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h index 3f1ee6aa46..fa8e5ed171 100644 --- a/libavutil/vulkan_loader.h +++ b/libavutil/vulkan_loader.h @@ -82,7

Re: [FFmpeg-devel] [PATCH] Remove unsafe bitwise OR on FFVulkanExtensions enum

2022-07-19 Thread Amir Mazzarella
Ping On Fri, Jul 8, 2022 at 8:57 PM Amir Mazzarella wrote: > FFVulkanExtensions enum does not have a value for 0 defined, and bitwise > OR on enums is not safe. The function returns uint64_t, so it makes more > sense and is safer to do arithmetic in terms of uint64_t > > Sign

Re: [FFmpeg-devel] [PATCH] Make implicit void pointer cast explicit

2022-07-19 Thread Amir Mazzarella
Ping On Fri, Jul 8, 2022 at 9:31 PM Amir Mazzarella wrote: > Signed-off-by: Amir Mazzarella > --- > libavutil/vulkan_loader.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h > index 3f1ee6aa

Re: [FFmpeg-devel] [PATCH] Make implicit void pointer cast explicit

2022-07-19 Thread Amir Mazzarella
even with extern "C", it won't be able to be compiled. On Tue, Jul 19, 2022 at 12:08 PM Nicolas George wrote: > Hi. Thanks for the patch. > > Amir Mazzarella (12022-07-09): > > Signed-off-by: Amir Mazzarella > > --- > > libavutil/vulkan_loader.h |

Re: [FFmpeg-devel] [PATCH] Make implicit void pointer cast explicit

2022-07-19 Thread Amir Mazzarella
On Tue, Jul 19, 2022 at 2:24 PM Nicolas George wrote: > Thanks for clarifying. I confess I had more or less guessed. FFmpeg is > C, and its headers, public or not, as a rule do not contain > accommodations to be included as is in other languages. I understand that FFmpeg does not contain accommod