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 64B294223A for ; Mon, 29 Aug 2022 15:01:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2AEB968BAB4; Mon, 29 Aug 2022 18:01:04 +0300 (EEST) Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 73D9B68BAB4 for ; Mon, 29 Aug 2022 18:00:58 +0300 (EEST) Received: by mail-oo1-f49.google.com with SMTP id d63-20020a4a5242000000b0044880019622so1494575oob.13 for ; Mon, 29 Aug 2022 08:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=7eazJmI6Gsss2y7xlNEHMBAomF5e527qn1f7GJKng+4=; b=dKF8V8T0z6Qb7wp2cfJtsCTTV4oJLH/E7Fi9ukEJ3kmB5C/vMNLHqTBaqQPrizMEXU 2KNxdSz1czsHik2PvccBwOk1n0Pl5q1eYwxOuB2gWRgoiWcnJw0FBUuPcqGkZZba4yn2 FOTqdVLXv0MvYGgo3HzBQdGbcc+tK1gIRW/Gl6/dLUM1aBJ+L1QlNoLdwKRj4F3dQdot cfmxOmV+rXC2spA0c5XutkIK8M3KLVZvgWyuEFuGdq7npcFRDnVkunSfjRmJeNc1IDOV SSC2l+tpvq8DjxfG9MAp0BIo3GLLPajo48Y3LblGwJopb/Gn+juBfFcjkW3tcfK6GuYM mvlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=7eazJmI6Gsss2y7xlNEHMBAomF5e527qn1f7GJKng+4=; b=Vh/RjyBpUoqyFhdvrhX7NnD5Xur/8oZ4X1M0+pFGC6XXUhhjzhFDU8KB1NBftIUlK2 QxRoHXJ1O+L+M9EPHTt4rNO2eO8Gim9P9QWeKLxKEmNj23yyig4qFRnq09TyJ5EjLFfw zctQl/8lzaem63coUG6IW+LO7PeSQSDJguoSslQg6Wx0hIx2+L4Y+aaUxV/QdU0sxwC9 6FlG7SKnBcBbCoXkWdkAqIq18ip7h1AFrUxbrvtf6UH9uXsAc96T4G2s6Rcmm0zTjlkD zeCcg+VShvOarNPo7s53nSr1Ls4latIjFBC0jS3aKqQVna3a3aWpzjeDj6VTYvfyTod2 KIfg== X-Gm-Message-State: ACgBeo0wqWZv4Ewuz9In3FPRQcpQs5wjWbBPR+MCfOlkipRJIV4lA42w F4ZsD2WidnkjCjKhwORbJtvlyCH45es= X-Google-Smtp-Source: AA6agR4rpHVwHvwwO1OH36PpdOXzuW7kgfy6sPs9F2EkDqelb89vxEd7MMWF6bMPX+0O2A4fR9hWig== X-Received: by 2002:a4a:5101:0:b0:441:a36d:4ec2 with SMTP id s1-20020a4a5101000000b00441a36d4ec2mr5689979ooa.13.1661785256277; Mon, 29 Aug 2022 08:00:56 -0700 (PDT) Received: from [192.168.0.13] ([191.97.187.183]) by smtp.gmail.com with ESMTPSA id i5-20020a4a4245000000b0041ba304546csm5225547ooj.1.2022.08.29.08.00.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Aug 2022 08:00:55 -0700 (PDT) Message-ID: <1263f749-8e56-9ba9-0b77-c031a73c8124@gmail.com> Date: Mon, 29 Aug 2022 12:00:54 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220829140717.26557-1-anton@khirnov.net> <20220829140717.26557-2-anton@khirnov.net> From: James Almer In-Reply-To: <20220829140717.26557-2-anton@khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH 2/3] lavu/fifo: clarify interaction of AV_FIFO_FLAG_AUTO_GROW with av_fifo_can_write() 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 8/29/2022 11:07 AM, Anton Khirnov wrote: > --- > libavutil/fifo.h | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/libavutil/fifo.h b/libavutil/fifo.h > index 6c6bd78842..89872d0972 100644 > --- a/libavutil/fifo.h > +++ b/libavutil/fifo.h > @@ -97,7 +97,13 @@ void av_fifo_auto_grow_limit(AVFifo *f, size_t max_elems); > size_t av_fifo_can_read(const AVFifo *f); > > /** > - * @return number of elements that can be written into the given FIFO. > + * @return Number of elements that can be written into the given FIFO without > + * growing it. > + * > + * In other words, this number of elements or less is guaranteed to fit > + * into the FIFO. More data may be written when the > + * AV_FIFO_FLAG_AUTO_GROW flag was specified at FIFO creation, but this > + * may involve memory allocation, which can fail. This patch is an API break, because before it i was told av_fifo_can_write() would tell me the amount of elements i could write into the FIFO, regardless of how it was created, but now it legitimates the one scenario where it was not reliable. An scenario i stumbled upon in my code by following the documentation, which is in at least one release, the LTS one. Instead of changing the documentation to fit the behavior, the behavior should match the documentation. This means that if a call to av_fifo_write() can succeed, then av_fifo_can_write() should reflect that. That said, it would be great if making av_fifo_can_write() tell the real amount of elements one can write into the FIFO was possible without breaking anything, but the doxy for av_fifo_grow2() says "On success, the FIFO will be large enough to hold exactly inc + av_fifo_can_read() + av_fifo_can_write()", a line that was obviously aware of the fact av_fifo_can_write() ignored the autogrow feature, and would no longer be true if said function is fixed. This could have been avoided if we added an av_fifo_size2() function that returned nb_elems, so the line above may have been replaced by one simply referring the user to it. But as is, we're breaking the API no matter what we do. > */ > size_t av_fifo_can_write(const AVFifo *f); > _______________________________________________ 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".