[FFmpeg-devel] size=0, but av_malloc(1)
chcunningham at google.com
Thu Mar 24 02:46:26 CET 2016
> Well, what else would you do?
In both cases I was expecting to see null instead of the 1 byte alloc.
In the case of the metadata, I was missing the subtlety about "no update"
vs "update to empty"... makes sense now.
malloc(0) can return NULL or non NULL whchever way libc prefers
> this makes reproducing bugreports harder if the developer and user
> have differening libcs
Makes sense, but then I wondered why not just skip malloc(0) and return
null. Your next sentence sheds some light.
also error checks become more complex if NULL can be a non error
> return value
Seems like the meat of the answer. I hadn't considered signalling error vs
empty in this way. IIUC this still isn't quite perfect since malloc itself
is not guaranteed to return null in the OOM error case... but then the ship
is probably going down anyway.
On Wed, Mar 23, 2016 at 1:56 PM, Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> On Wed, Mar 23, 2016 at 03:31:38PM +0100, Michael Niedermayer wrote:
> > On Tue, Mar 22, 2016 at 11:43:50PM -0700, Chris Cunningham wrote:
> > > Hey Group,
> > >
> > > I'm seeing an interesting pattern  where we allocate 1 byte in
> > > where I would expect no allocation to be necessary. Why is this being
> > >
> > >  https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/mem.c#L136
> > > 
> > >
> > to add another reason why malloc(0) _can_ be a problem
> > malloc(0) can return NULL or non NULL whchever way libc prefers
> > this makes reproducing bugreports harder if the developer and user
> > have differening libcs
> > also error checks become more complex if NULL can be a non error
> > return value
> Since you already said that: if that code used malloc(0) - note I
> don't know about av_malloc - and it returned 0, the behaviour would
> be incorrect.
> In this code, a NULL pointer means "no metadata update" which is very
> different from "metadata update to empty metadata".
> Also even if it does not return NULL it could always return the same
> pointer, which could trigger yet another class of bugs (probably
> not in this case though).
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel