James Almer (12021-12-08): > What is wrong with it? All the functions returning a string in this API use > the same signature. You pass it a pre-allocated buffer and it's filled with > the string, truncating it if there's not enough space and letting the user > know about it. > I recall you were against dynamic allocation of the string, which the user > then had to free, so this was the alternative.
There is nothing wrong with it, just as there is nothing wrong with wearing pelts and a loincloth, but modern clothes are much more comfortable. In this case, there is a little usability issue: this description is almost always very short but can be arbitrarily long, handling that properly in the caller is very annoying: start with a small buffer on the stack, try the conversion, if it fails start allocating a bigger buffer on the heap, etc. > I could make it use a user provided AVBprint buffer instead of using one > internally, if you think that's better, but since you planned to replace > that with AVWriter i figured using AVBprint in the signature would mean an > eventual deprecation and removal. We are on the same page on this. A memory allocation would be a big no here, because it can happen once every frame. We have implemented pools for frames and buffers, we do consider once-per-frame to be frequent enough to warrant code to avoid allocations. My preferred outcome would be that we apply AVWriter before this series, and using it here. The idea would be to start using AVWriter everywhere we return some kind of string: AVWriter in one or two places is crap, but the more we use it, the more its benefits outweigh the costs. I will start a new discussion on string API soon, and since we do not really disagree here but the rest will take some time, we can continue discussing this later. 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-requ...@ffmpeg.org with subject "unsubscribe".
