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 10B1641030 for ; Sun, 2 Jan 2022 20:46:39 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 14F4868B183; Sun, 2 Jan 2022 22:46:37 +0200 (EET) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1CB0A68A2F6 for ; Sun, 2 Jan 2022 22:46:31 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 7A48BE659F for ; Sun, 2 Jan 2022 21:46:30 +0100 (CET) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utVsYqkJ7Aym for ; Sun, 2 Jan 2022 21:46:28 +0100 (CET) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 67BD8E659D for ; Sun, 2 Jan 2022 21:46:28 +0100 (CET) Date: Sun, 2 Jan 2022 21:46:28 +0100 (CET) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <23148c44-cec7-8d6c-6060-f719bea7c65c@passwd.hu> Message-ID: <1d8844a-2412-889-2f42-6f0216a4210@passwd.hu> References: <20211227002613.25069-1-cus@passwd.hu> <23148c44-cec7-8d6c-6060-f719bea7c65c@passwd.hu> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/5] avformat/aviobuf: set AVIOContext->error on bprint buffer ENOMEM 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 Fri, 31 Dec 2021, Marton Balint wrote: > > > On Fri, 31 Dec 2021, Andreas Rheinhardt wrote: > >> Marton Balint: >>> This makes sure the error condition is kept in AVIOContext even if the >>> user >>> does not check the return value of avio_read_to_bprint or >>> ff_read_line_to_bprint. >>> >>> Signed-off-by: Marton Balint >>> --- >>> libavformat/aviobuf.c | 8 ++++++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c >>> index 29d4bd7510..6f8a822ee3 100644 >>> --- a/libavformat/aviobuf.c >>> +++ b/libavformat/aviobuf.c >>> @@ -875,8 +875,10 @@ static int64_t >>> read_string_to_bprint_overwrite(AVIOContext *s, AVBPrint *bp, >>> if (ret < 0) >>> return ret; >>> >>> - if (!av_bprint_is_complete(bp)) >>> + if (!av_bprint_is_complete(bp)) { >>> + s->error = AVERROR(ENOMEM); >>> return AVERROR(ENOMEM); >>> + } >>> >>> return bp->len; >>> } >>> @@ -1351,8 +1353,10 @@ int avio_read_to_bprint(AVIOContext *h, AVBPrint >>> *pb, size_t max_size) >>> if (ret <= 0) >>> return ret; >>> av_bprint_append_data(pb, buf, ret); >>> - if (!av_bprint_is_complete(pb)) >>> + if (!av_bprint_is_complete(pb)) { >>> + h->error = AVERROR(ENOMEM); >>> return AVERROR(ENOMEM); >>> + } >>> max_size -= ret; >>> } >>> return 0; >>> >> >> I don't really see the point of this: It is not a real read error that >> should stick to the AVIOContext (which can still be used afterwards >> without any issue). >> If the user does not check the errors, then the user >> has no one to blame but himself for missing errors. > > AVIO read/write behaviour is to store IO errors in the context so the user > does not have to check for them in every call. It is not well documented > which calls should be checked always, so the user might be under the > impression that errors during read/write may be checked sometime later. > > Admittedly, ENOMEM is not an IO error, but I think it is better to store that > as well in the context to keep the behaviour consistent, because in case of > ENOMEM avio_read_to_bprint reads and drops undefined amount of data, so the > context will also be in an undefined state. > > Other possibilities: > - make avio_read_to_bprint read all the data regardless of AVBPrint fullness > - mark avio_read_to_bprint av_warn_unused_result. > - both :) > > But these also forces the user to check return values... So I kind of like my > original approach better, because it maintains avio_read/write call behaviour > that it is safe to check errors sometime later. Any more comments about this or the rest of the series? I plan to apply it tomorrow. Thanks, Marton _______________________________________________ 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".