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

[Nicolas George <george@nsup.org>]

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.

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.

> 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.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".