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

[Stefano Sabatini]

On date Wednesday 2021-12-22 17:12:41 +0100, Nicolas George wrote:
> Hi.
> 
> I will try again proposing a good string API for the project. But this
> time, instead of showing the implementation code, I will ask about the
> principle.
> 
> So, please, read the argument, and give your opinion on the principle.
> If we agree on the principle, we can discuss the code then.
[...]
> * What string API we should use
> 
> We have AVBprint, but the API is ugly, and it only brings a few of the
> benefits I promised. I have a proposal: AVWriter.
> 
> I posted it last spring, here is an introduction on how to use it (with
> the implementation in the same thread):
> 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-April/279383.html
> 
> 
> * Conclusion
> 
> Well, I am convinced, but what about you?
> 
> 1. Do you think FFmpeg needs a good string API? If not, please explain
> why?
> 
> 2. Assuming we agree ‘yes’ on the previous question, do you think
> AVWriter is a good candidate? If not, what else would you propose?

Hi, and sorry for the long delay (I'll comment soon about the AVWriter
API).

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?

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)?