From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 060C642FA8 for ; Thu, 16 Jun 2022 15:47:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BE4C868B7E0; Thu, 16 Jun 2022 18:47:48 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 676B568B0FB for ; Thu, 16 Jun 2022 18:47:42 +0300 (EEST) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 25GFleOD029864 for ; Thu, 16 Jun 2022 17:47:41 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id E1402E1DC8; Thu, 16 Jun 2022 17:47:40 +0200 (CEST) Date: Thu, 16 Jun 2022 17:47:40 +0200 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20220615205649.GD11679@mariano> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220615205649.GD11679@mariano> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Thu, 16 Jun 2022 17:47:41 +0200 (CEST) Subject: Re: [FFmpeg-devel] The case for a good string API X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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".