C11 required to use ATOMIC_VAR_INIT to statically initialize
atomic objects with static storage duration. Yet this macro
was unsuitable for initializing structures [1] and was actually
unneeded for all known implementations (this includes our
compatibility fallback implementations which simply wrap the value
in parentheses: #define ATOMIC_VAR_INIT(value) (value)).
Therefore C17 deprecated the macro and C23 actually removed it [2].
Since commit 5ff0eb34d2 we default
to C17 if the compiler supports it; Clang warns about ATOMIC_VAR_INIT
in this mode. Given that no implementation ever needed this macro,
this commit stops using it to avoid this warning.
[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_485
[2]: https://en.cppreference.com/w/c/atomic/ATOMIC_VAR_INIT
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.
Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.
This patch limits the maximum alignment to the maximum possible simd
alignment according to configure.
While not perfect, it at the very least gets rid of a lot of UB, by
matching up the maximum DECLARE_ALIGNED value with the alignment of heap
allocations done by lavu.
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.
Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.
This patch limits the maximum alignment to the maximum possible simd
alignment according to configure.
While not perfect, it at the very least gets rid of a lot of UB, by
matching up the maximum DECLARE_ALIGNED value with the alignment of heap
allocations done by lavu.
av_fast_realloc and av_fast_mallocz? store the size of
the objects they allocate in an unsigned. Yet they overallocate
and currently they can allocate more than UINT_MAX bytes
in case a user has requested a size of about UINT_MAX * 16 / 17
or more if SIZE_MAX > UINT_MAX (and if the user increased
max_alloc_size via av_max_alloc). In this case it is impossible
to store the true size of the buffer via the unsigned*;
future requests are likely to use the (re)allocation codepath
even if the buffer is actually large enough because of
the incorrect size.
Fix this by ensuring that the actually allocated size
always fits into an unsigned. (This entails erroring out
in case the user requested more than UINT_MAX.)
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some of these were made possible by moving several common macros to
libavutil/macros.h.
While just at it, also improve the other headers a bit.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does the same as av_calloc(), so one of them should be removed.
Given that av_calloc() has the shorter name, it is retained.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since 580e168a94, av_size_mult() is no
longer inlined; on systems where interposing is a thing, this also
inhibits the compiler from inlining said function into the internal
callers of said function, although inlining such a small function is
typically beneficial: With GCC 10.3 on Ubuntu x64 and -O3 this decreases
the size of av_realloc_array from 91B to 23B, from 129B to 81B for
av_realloc_f and from 77B to 23B for each of av_malloc_array,
av_mallocz_array and av_calloc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The size of a single allocation performed by av_malloc() or av_realloc()
is supposed to be bounded by max_alloc_size, which defaults to INT_MAX
and can be set by the user; yet currently this is not completely
honoured: The actual value used is max_alloc_size - 32. How this came
to be can only be understood historically:
a) 0ecca7a49f disallowed allocations
> INT_MAX. At that time the size parameter of av_malloc() was an
unsigned and the commentary added ("lets disallow possible ambiguous
cases") indicates that this was done as a precaution against calling the
functions with negative int values. Genuinely limiting the size of
allocations to INT_MAX doesn't seem to have been the intention given
that at this time the memalign hack introduced in commit
da9b170c6f (which when enabled increased
the size of allocations slightly so that one can return a correctly
aligned pointer that actually does not point to the beginning of the
allocated buffer) was already present.
b) Said memalign hack allocated 17 bytes more than actually desired, yet
allocating 16 bytes more is actually enough and so this was changed in
a9493601638b048c44751956d2360f215918800c; this commit also replaced
INT_MAX by INT_MAX - 16 (and made the limit therefore a limit on the size
of the allocated buffer), but kept the comment, although there is nothing
ambiguous about allocating (INT_MAX - 16)..INT_MAX.
c) 13dfce3d44 then increased 16 to 32 for
AVX, 6b4c0be558 replaced INT_MAX by
MAX_MALLOC_SIZE (which was of course defined to be INT_MAX) and
5a8e994287 added max_alloc_size and made
it user-selectable.
d) 4fb311c804 then dropped the memalign
hack, yet it kept the -32 (probably because the comment about ambiguous
cases was still present?), although it is no longer needed at all after
this commit. Therefore this commit removes it and uses max_alloc_size
directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do not limit the array allocation functions and av_calloc() to allocations
of INT_MAX, instead depend on max_alloc_size like av_malloc().
Allows a workaround for ticket #7140.
Inlining public functions hardcodes their implementation into the ABI,
so it should be avoided unless there is a very good reason for it. No
such reason exists in this case.
The original code assumes av_realloc() will free ptr if size is zero.
The assumes is incorrect now.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
internal.h is difficult to use due to circular dependancies
mem.h is a public header ff_* is not public
Alternative solutions probably are possible too
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This uses explicit memory copying to read and write pointer to pointers
of arbitrary object types. This works provided that the architecture
uses the same representation for all pointer types (the previous code
made that assumption already anyway).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
av_dynarray_add_nofree function have similar functionality
as existing av_dynarray_add, but it doesn't deallocate memory
on fails.
Signed-off-by: Lukasz Marek <lukasz.m.luki@gmail.com>
This makes sure that pointers from av_strdup are reallocable,
which is used in av_dict_set if the AV_DICT_APPEND flag is set.
Nothing should rely on pointers from av_strdup being aligned.
Signed-off-by: Martin Storsjö <martin@martin.st>
Andreas Rheinhardt
Timo Rothenpieler
James Almer
Anton Khirnov
Andreas Rheinhardt
Carl Eugen Hoyos
Michael Niedermayer
James Darnley
Diego Biurrun
Timothy Gu
Zhao Zhili
Michael Niedermayer
Rémi Denis-Courmont
Lukasz Marek
Nicolas George
Martin Storsjö
Luca Barbato
Stefano Sabatini