From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 1DBC34E028 for ; Sun, 6 Jul 2025 14:34:08 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 3E5D068C0D9; Sun, 6 Jul 2025 17:34:03 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id B6B0D690715 for ; Sun, 6 Jul 2025 17:33:56 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 88709443AA for ; Sun, 6 Jul 2025 14:33:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1751812435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KZLqwXdFJFagxTij5NB6ctDoT0sD++a5MpuP4SEVf8w=; b=beLYKnbe6Rjugh6h7JXxlHayUDCs3UUPNO3K7Rr8IDF5qajYCvBcQhdNFrRs1gy5wAXZTD FtlohCmmQsRxbC7F8UO+uI75wbi+XlxyOmHdXX2/dClH6KFTp3V7oIwx+V7apIgtMXXBRo +OCryNIvzPfByCE6SMnc3fF6H8VcgQQKeYMwv8LRT3Khym7/ZDAkEydGLYnmceyw9AnrIK ZqNBoV7BF/wb9iXmM3XmaAHl5vpOD69Is0fQOshuzr3M/zFYyo/8alTCJyFXP3qAYvz+9G ohNcV61prvmxvzHQll8ANcvgNSUf1T8usCbJP4SJAYEzCOvRIGTZraIzQPSvqg== Date: Sun, 6 Jul 2025 16:33:54 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250706143354.GA29660@pb2> References: <20250702144355.GE29660@pb2> <20250702171641.GF29660@pb2> <20250703155205.GK29660@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddvledujecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdlfedtmdenucfjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofhitghhrggvlhcupfhivgguvghrmhgrhigvrhcuoehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgeqnecuggftrfgrthhtvghrnhepleekgefgffeiudefjeeuffejudehtddtudeltdehveevvedtieeulefhtdeutdeknecukfhppeeguddrieeirdeiiedrvddvjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeguddrieeirdeiiedrvddvjedphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepfhhfmhhpvghgqdguvghvvghlsehffhhmphgvghdrohhrgh X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [RFC] Advanced 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: multipart/mixed; boundary="===============6193856041246743900==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6193856041246743900== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3Fw9l56zWY0etGZq" Content-Disposition: inline --3Fw9l56zWY0etGZq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Nicolas On Fri, Jul 04, 2025 at 03:29:19PM +0200, Nicolas George wrote: > Michael Niedermayer (HE12025-07-03): > > return av_adv_err_new(AVERROR_INVALIDDATA, "Garbled foobar data", "Foo = triangle quantum decoder" > > __FILE__, __LINE__, NULL, "Whaetver you like %s",= favorite_food); > >=20 > > teh return type is int64_t here >=20 > So we need to change all our return types? no we can do it with int too, if thats preferred. >=20 > > this also cannot fail as it allocates nothing >=20 > Where does the memory storing =E2=80=9Cfavorite_food=E2=80=9D come from? theres a fixed length array of AdvancedError structs. AdvancedError has a fixed length char field. Thats where a single custom text string can be stored. Which would be maybe "Whaetver you like pizza" if favorite_food was "pizza" its very very simple typdef struct AdvancedError { const char *error_name; ///< like "Timeout" or "Invalid= Bitstream" const char *operation_name; ///< like "Network Read" or "H.264 b= lock parsing" const char *source_filename; ///< like ffmpeg.c int source_line_number; ///< like 123 for line 123 in ffmpeg.c char free_form_description[FREE_FORM_LEN]; ///< anything extra that do= esnt fit in pointers to static const strings int64_t this_error; int64_t previous_error; ///< A previous related error, if any int64_t timestamp; ///< Timestamp at which the error occu= red int thread_id; } AdvancedError; struct AdvancedError advanced_error[MAX_CONCURRENT_ERRORS]; >=20 > > it also needs no context but would use a mutex or thread local storage > >=20 > > the message length would be bound by a maximum, >=20 > Of course. >=20 > > I am not sure if passing a context around is going to find the voluntee= rs > > to implement and maintain. Also it has a performance impact for small a= nd > > lightweight functions. >=20 > We already pass contexts around everywhere. * Many places but not everywhere, * The contexts do not match the lifetime of the errors * The contexts can be accessed from multiple threads * There can be multiple relevant errors for a single context >=20 > I would argue that the small lightweight functions that do not already > have a context for the error are too low level to be able to provide a > meaningful error message. "square root of negative argument" in mydecoder.c at line 123 is more informative than EINVAL, and having no clue where or why that happened for example decode() returning AVERROR(EINVAL) with 5000 lines of cryptic parser errors in messages vs. "square root of negative argument" in mydecoder.c at line 123, called by vector_length_compute() line 511 called by read_nnet() line 732 free_form_description=3D"training_set_maybe_corrupted.= dat" Note by the time this is returned decode failed and many contexts have been destroyed. >=20 > So, my proposal is similar to yours, except for the following > differences: >=20 > - We allocate the memory for error messages contexts. That way, we avoid > the issue of using locks or thread-local storage but do not have a > hard limit on simultaneous errors. malloc() can fail and it needs to be freed exactly once. And not freed before the caller is finished doing anything it likes to do with the error information. And it very possibly wants to pass it on to its caller >=20 > - We do not change the return type of all our API, we still return =E2=80= =9Ca > negative AVERROR code=E2=80=9D to keep source compatibility, and use th= e best > code we can find. Then you no longer know which error relates to which message So the problem that I see, isnt solved. Maybe it helps with other problems, i dont know. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator --3Fw9l56zWY0etGZq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaGqJTgAKCRBhHseHBAsP qyQZAJ9XeIAypguylElRizAqdkVoYlbjDgCeJg/MIrJfVorokktlNInXQ3nc4Qw= =7HWJ -----END PGP SIGNATURE----- --3Fw9l56zWY0etGZq-- --===============6193856041246743900== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============6193856041246743900==--