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 7B865473C6 for ; Wed, 6 Sep 2023 11:13:37 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5013268C7B0; Wed, 6 Sep 2023 14:13:34 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A78E768C5FB for ; Wed, 6 Sep 2023 14:13:27 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 5C4242401C0 for ; Wed, 6 Sep 2023 13:13:27 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id pCIFTX8T_JeO for ; Wed, 6 Sep 2023 13:13:26 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 81D28240177 for ; Wed, 6 Sep 2023 13:13:26 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id A10E91601B9; Wed, 6 Sep 2023 13:13:25 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20230826122328.95416-1-stefasab@gmail.com> <169306293626.20400.4712343328864304301@lain.khirnov.net> <169358345620.20400.6777068619760269139@lain.khirnov.net> <169391274067.20400.12945788077351942626@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 06 Sep 2023 13:13:25 +0200 Message-ID: <169399880562.20400.15389167820793227268@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] lsws/swscale.h: introduce sws_get_gaussian_vec 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: Quoting Stefano Sabatini (2023-09-06 00:59:44) > > > > As I already said above - function parameter names in a prototype are > > > > purely cosmetic and have no effect on anything besides doxygen. You can > > > > change them at will and even remove them entirely without breaking API > > > > or ABI. > > > > > > > > > > > The other reasons do not strike me as strong enough to warrant an API > > > > break. > > > > > > > I disagree on this: the function is probably only used internally and > > > by libavfilter, and the migration is trivial enough so should cause no > > > disruption anyway. > > > > > The migration is not trivial for someone who is not familiar with the > > code (such as a distro package maintainer), since the new function has a > > different signature. I really do not think we should break APIs for > > frivolous reasons, which includes cosmetic ones. > > Following this logic every API change should be considered not trivial > for someone not familiar with the code, A simple rename is a trivial API change. Almost everything else is not. > and therefore should not be committed. Yes, the baseline for every API change is that it is undesirable and you must supply sufficiently strong arguments to overcome that. > Also there is no evidence that external components are using this > function. > > Besides the naming change, there are ergonomic and functional changes > making the behavior of the code more correct. I do not see the code being made more correct, but Michael observed in this thread that it becomes longer and more convoluted. I am not convinced that adding logging to this function is an improvement. You have to pass an extra parameter to every call, making the code longer and less readable. We do not need a dedicated error message for every malloc. -- Anton Khirnov _______________________________________________ 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".