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 5B9664A590 for ; Sun, 2 Jun 2024 10:43:15 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 34AC168D620; Sun, 2 Jun 2024 13:43:13 +0300 (EEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5E3B568D36D for ; Sun, 2 Jun 2024 13:43:06 +0300 (EEST) X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from metallschleimette ([91.62.13.127]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N1fii-1sc0ob28r2-011C9B for ; Sun, 02 Jun 2024 12:43:05 +0200 Date: Sun, 2 Jun 2024 12:43:04 +0200 To: FFmpeg development discussions and patches Message-ID: References: <20240529145955.32189-1-remi@remlab.net> <2666279.WWoxFUQ57l@basile.remlab.net> <8140292.HjBHnJclMf@basile.remlab.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8140292.HjBHnJclMf@basile.remlab.net> X-Provags-ID: V03:K1:ycxbHqb+i6oac3ukMTJ3PuTUgbqX5djX7QiBmBbRXXn34ClxjNt 6WLdDJ0ycLD2yG2/uQQar7AB28iXl+YhgWqfJZjRIWVW5ylfiiXeRbPBRAvofCGijrlNGeC PqwaEYhntal5ZOT1XAwDrrPlPSglE6LG7hD2BuXuUBObKbQoLAOUuStUxVPGHLhJdQeTGbu btmTqPv6Wja1KL3VoEa6w== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:hEyW9gTJpyQ=;0cKbidEqnugC9Bq2UXKRPRjJFv6 udOEf/x1zcbDUqfYj0YHJhzcjInrGqkIbjt2ObEjmljjBF5EPrA3gtDKxQ60Iq7mTu2Keu6wg qqcT/QniFqeBO187R1J3sbd4yOKfI+Lfs2HVCiyYBp6lVytR8rYwlBF7DxjjIe9VEf/wpzCvd 3vTKtdaw3olpmBgDj59e8Ps5ivX0IEiHh/hw3nBao4UyUk00eXsSNeqssgvMVOhv1PxTGUtB4 wyKjSwil6meKyERsnP28HUvL6A2MjzZC/OyfuHSVqpPd7t7+mY8/sZk/xxIk+UvU/6qVxPyNJ t52Ifz8Ge2iwRh5TkjW7pgWHGe8ri1tmR7BM5SUn4hfSescQ8zngJ+o6mrM/VErPU1s0HG9CR 5x+N6wGuX0xjO9sjjmj8mWHOTNQ8sO2g6ERMHzQHPXmhegta2+6Cp0Gy+fWEFH/9LXwcZGF5x 1xDLrVb4Nrs2arwolBjXiQjR31UjNDzZg5NPC6c3lQ0lxeJAURhmh9j8S+5fP9o3eDJOU7kBP DsYygSttSsblJIh5ri7hMVmWMv+w1Jy6KCM7x2JvW7oblcP3reKr6+kkr/NhZzd4kpCYQg6wn 3NKlL8OywHl5rkU9uVc/X2Z+2E+5rXbADNBScU2Ra3K4/4mKNtQrmbj8PtJi7TgfxfESEcQgX 0Cj7RpF0YSiZB+bWNQQVD2oxppaoC/l1P1Fekdk6uuUVwAzj7eq9fuGcRAeGq47TZgQMgJMcA R0W47bn0ZVgi9UHhpF4SWffJ1JeMELV13WTPJQmIJdS3eRTHF0nGwYeHO8M2SSUlfXYH8vGCk hJdH08VWW8D291TWHpoxbCPqTVfooH23XkujhrWusrcbo= Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavu/float_dsp: add double-precision scalar product 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: , From: Alexander Strasser via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Alexander Strasser Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2024-06-02 13:30 +0300, R=E9mi Denis-Courmont wrote: > Le sunnuntaina 2. kes=E4kuuta 2024, 13.04.05 EEST Alexander Strasser via = ffmpeg- > devel a =E9crit : > > On 2024-05-29 18:51 +0300, R=E9mi Denis-Courmont wrote: > > > Le keskiviikkona 29. toukokuuta 2024, 18.44.13 EEST Andreas Rheinhard= t a > > > =E9crit> > > > > > +static double ff_scalarproduct_double_c(const double *v1, > > > > > > > > Don't use an ff_ prefix for a static function. > > > > > > I can see over 300 such identifiers in the code base (many but not all > > > inline), and I don't see why that would be a problem. > > > > I agree that it's not a problem regarding on the functional side, > > OTOH regarding coding conventions we try to consistently follow it's > > misleading as the ff_ prefix indicates a bigger scope of sharing. > > Anybody can see the 'static' qualifier literally in front to see the func= tion > is not in a bigger scope of sharing. And if you do somehow miss and try t= o use > the function, you will get a linker error. > > The only case where this *actually* matters is in debugging. And exactly = then > it is much better to use the ff_ prefix *because* all symbols, including = local > ones like this, end up sharing the namespace. But not at the call site? > > I think Andreas remark is correct and it would be better to not use ff_ > > prefix wrongly when adding new code. > > IMO, it is worse. I tend to disagree here as it makes the meaning of the ff_ prefix arbitrary. Anyway if you want to challenge this convention we are using since many yea= rs in this code base, I suggest to do it in a separate discussion thread. Alexander _______________________________________________ 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".