[FFmpeg-devel] [PATCH 10/10] avformat/nutenc: Don't allocate array with zero entries

[Michael Niedermayer]

On Sat, May 09, 2020 at 06:52:35AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, May 04, 2020 at 08:22:50PM +0200, Andreas Rheinhardt wrote:
> >> Allocating an array with zero entries is both unnecessary as well as
> >> potentially troublesome because the behaviour in this case is not really
> >> well defined.
> > 
> > What is not well defined ?
> > 
> The behaviour of our memory-allocation functions in case one requests to
> allocate zero bytes is not well-defined (does it return NULL or not?).
> E.g. although the documentation of av_mallocz_array() (which applies to
> av_calloc, too) treats the size and nmemb parameters symmetrically, the
> actual implementation differed until commit
> b7d9507bb8c4d1b8bf99158d6859a5b2ecd73298 (up until then, a size of zero
> would have resulted in NULL being returned). In the discussion [1]
> around this patch there were devs favouring returning NULL upon any
> request to allocate zero bytes. The NUT muxer is btw one of the two main
> reasons for failing fate-tests in case one returned NULL when an
> allocation of zero bytes is requested.
> 
> What happens on allocation of zero bytes is implementation-defined for
> the analogous C functions; in our implementation the only function that
> explicitly documents what happens when the size fed to it is zero is

IMO The intended behavor of the allocation functions was to return NULL on
failure only.

That way a NULL test can be used for testing for failure without special
cases. Also it avoids special cases with NULL pointers with functions which
do not allow NULL even for size = 0.
I think at minimum a succeeding *malloc(x) should work with *memcpy(x)/*memset(x)/...
of the same API.
if the later are undefined with NULL so the first should not produce NULL on
success.

> av_realloc() which does not abide by its documentation (it does not free
> anything when size is zero, but rather reallocates the buffer to a size
> of one).

Thats an interresting bug

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200509/c1e5a7fd/attachment.sig>