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 CFE9748739 for ; Tue, 16 Jul 2024 11:16:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ABAE568D93E; Tue, 16 Jul 2024 14:16:06 +0300 (EEST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id BF4D668D538 for ; Tue, 16 Jul 2024 14:15:59 +0300 (EEST) Received: from 0.b.4.b.7.4.0.8.c.4.a.5.d.8.b.2.0.5.8.0.9.1.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:819:850:2b8d:5a4c:8047:b4b0] helo=andrews-2024-laptop.lan) by painless-b.tch.aa.net.uk with esmtp (Exim 4.96) (envelope-from ) id 1sTgA3-000oNM-0o for ffmpeg-devel@ffmpeg.org; Tue, 16 Jul 2024 12:15:59 +0100 From: Andrew Sayers To: ffmpeg-devel@ffmpeg.org Date: Tue, 16 Jul 2024 12:13:09 +0100 Message-ID: <20240716111543.2437488-1-ffmpeg-devel@pileofstuff.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <9e16396a-4ef2-fdb3-fce8-94e19a141473@passwd.hu> References: <9e16396a-4ef2-fdb3-fce8-94e19a141473@passwd.hu> MIME-Version: 1.0 Subject: [FFmpeg-devel] [RFC PATCH v2 0/1] avutil/error: Provide better feedback about unknown error codes 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: I'm having trouble managing this conversation. On one hand, you've brought up several important details that would need to be included in a new patch. On the other hand, I'm pretty sure we're talking past each other on the big problems, and need to start over. So let's fork the discussion. # First, let's haggle over some details The patch below fixes a number of small issues brought up by your comments... Error numbers are always expressed in the code as either uppercase hex numbers or FourCCs (or ThreeCCs, but you get the point). This patch prints error codes as hex, which is no less unintelligible for ordinary users, might make problems easier to find on Google, and will sometimes make them easier to grep for. Having said that, this patch prints non-negative numbers in decimal, because all bets are off if that manages to happen. A developer could create an error code that just happens to be valid ASCII. In that situation, the previous patch would have printed something like "Unrecognised error code \"~!X\"" occurred", which is worse than the current behaviour. This patch includes both (hex) number and name in those messages. This patch adds "please report this bug" for all unknown error messages. I'll cover the reasoning below, but the relevant detail is that the previous patch just gave users a different heiroglyphic before abandoning them. # Second, let's talk about the big picture Consider the following scenario: 1. a new developer adds some code to FFmpeg that calls an existing function 2. it turns out that function sometimes calls another function that returns a variety of internal error codes (FFERROR_REDO among others) 3. their testing uncovers a situation that intermittently returns an unknown error number, but they don't notice there are two different numbers 4. they spend a lot of time tracking down an error message based on a random number, and eventually fix "the" bug (actually one of two intermittent bugs) 5. the review doesn't catch the other bug, and the new code goes live 6. a user trips over the other bug and sees "Error number occurred" 7. the user wastes a lot of time trying to work out what they did wrong, badmouthing FFmpeg to anyone who will listen as they do 8. they eventually catch the attention of a developer 9. that developer spends a lot of time bisecting the bug 10. the new developer is expected to fix this patch, and feels like they're to blame for the whole situation An error message like "Unrecognised error code \"REDO\" occurred, please report this bug" would give the newbie a fighting chance to catch both bugs at step 3, would make step 4 much shorter, and would optimise steps 7-10 to almost nothing. Catching this in a fate test would involve checking for an unknown function returning an unknown number that gets reused in a context it's subtly inappropriate for. I have no idea where to begin with that, and anyway it wouldn't help a developer in the process of tracking down an intermittent bug. As mentioned above, the v2 patch adds "please report this bug" in a few places. Any negative error code can be valid, but returning a raw error number is always a bug, so it's all the same to users - if they see this message, they're not expected to fix it themselves, they're expected to let us know. _______________________________________________ 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".