[FFmpeg-devel] The case for a good string API

[Stefano Sabatini]

Hi Nicolas!

On date Thursday 2022-06-16 17:47:40 +0200, Nicolas George wrote:
> Stefano Sabatini (12022-06-15):
> > Hi, and sorry for the long delay (I'll comment soon about the AVWriter
> > API).
> 
> Thanks. I was starting to despair that somebody else gives a damn about
> it.
> 
> > Before jumping to the discussion, probably it's good to think a bit
> > about the bprint.h API and its limitations (the ones which come to mind
> > are: no errors in case of truncation, and possible inefficiency due to
> > the realloc). So while it covers the case for small strings (and it's
> > not that bad IMO from the API point of view), probably it's underkill
> > for data serialization.
> > 
> > Do you have more in mind about its limitations?
> 
> The limitations of BPrint were one of the motivations to start working
> on this. But I am not sure what you are referring to exactly.
> 

> BPrint already has a means to test for truncation in case of memory
> allocation failure. I tried to make it a little harder to forget with
> dynamic AVWriter,  but it is a fine line between harder to forget and
> annoying to use.

Right, I completely forgot about it.

> Regarding realloc(), I am even more confused: we cannot avoid a dynamic
> allocation if the string is larger than the initial buffer. But AVWriter
> goes a step further in that direction: if you want to write to a file or
> to the network, it can do so on the fly, without using a dynamic buffer.

I was thinking about mempool (and no, I don't think it's really
neeeded for this use case).

I still had to read the implementation, now I think I got what this is
about.

> > Also, is the new API supposed to be a replacement for AVBprint or is
> > it supposed to live in parallel with it (to serve different purposes)?
> 
> Eventually, I would like to have all useful features of BPrint in the
> dynamic buffer AVWriter and deprecate BPrint, since that was written in
> part to learn and do BPrint better.

OK, sounds good.