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 BCB8F4553D for ; Tue, 31 Jan 2023 21:16:11 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7728A68BE95; Tue, 31 Jan 2023 23:16:08 +0200 (EET) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C7BC268BE82 for ; Tue, 31 Jan 2023 23:16:01 +0200 (EET) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 30VLG1nt003600 for ; Tue, 31 Jan 2023 22:16:01 +0100 Received: by phare.normalesup.org (Postfix, from userid 1001) id ED712EB5BB; Tue, 31 Jan 2023 22:16:00 +0100 (CET) Date: Tue, 31 Jan 2023 22:16:00 +0100 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20230130122937.12258-1-anton@khirnov.net> <167517302897.4503.15130184316413800795@lain.khirnov.net> <167517470800.4503.4882536660599256492@lain.khirnov.net> <167517869808.4503.13103529212008047943@lain.khirnov.net> MIME-Version: 1.0 In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Tue, 31 Jan 2023 22:16:01 +0100 (CET) Subject: Re: [FFmpeg-devel] [PATCH] lavfi: get rid of FF_INTERNAL_FIELDS 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="===============7345420159595288695==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7345420159595288695== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RqnqwLwXz/XASGr6" Content-Disposition: inline --RqnqwLwXz/XASGr6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andreas Rheinhardt (12023-01-31): > Details please. I was not going to spend time explaining unless I had assurance it was because the issue of requiring changes in the internal implementation and developers habits just to hide some fields was taken into account. Coming from somebody else, I would have expected the question to be only to find the first excuses to shoot the proposal down. But you more or less found the same ideas I did anyway. > I can only think of the following: > a) Allow the use of -fms-extensions. This allows structs with tags and > typedefs thereof to be used as unnamed struct members with the members > of the unnamed structure being treated as members of the enclosing > structure. One could then use a pointer to the big internal structure > internally and one does not need to remember whether a field is internal > or not. There is still a problem, though: One needs to cast from > AVFilterContext.(inputs|outputs). This should be done via dedicated > inlined getters, but this is a bit more typing. E.g. > "input_from_ctx(ctx, i)" instead of "ctx->inputs[i]". Of course, it > might also be shorter if someone has a short name. > GCC, Clang, MSVC and the IIRC the intel compilers support this. >=20 > b) Add a big #define AVFILTERLINK in avfilter.h that expands to the > public part of AVFilterLink and change the declaration of AVFilterLink > to "struct AVFilterLink { AVFILTERLINK };" and use declare the internal > struct via > "struct FilterLinkInternal { > AVFILTERLINK > /* actual internal fields */ > };" > This has the downside of actually being an aliasing violation and of > adding considerable ugliness to avfilter.h, in particular during > deprecations (like with FF_API_OLD_CHANNEL_LAYOUT -- you can't check via > #if in the implementation of a macro). I also don't know whether it > plays nicely with tools that deal with source code annotations. Or use a =E2=80=9C#include "avfilter_link_internal_fields.h" instead of a m= acro. > c) Wrap the internal part in an #ifdef HAVE_AV_CONFIG_H, optionally > using #if defined(HAVE_AV_CONFIG_H) && defined(BUILDING_avfilter). > d) Same as c), but strip this stuff from installed headers. >=20 > I consider b)-d) as inferior to a), which I consider superior to Anton's > proposal, but the big drawback is its reliance on a compiler extension. Once and for all: If the solution requires changing things in the internal implementation C files and changing the habits of the people who work on these files (that goes together), then it is inferior to a solution that does not require that. Your solution (a) has this flaw, plus relies on an extension that is probably not available on all supported platforms (Microsoft I am looking at you). My favor goes to (d). Probably with a stricter test for the (c) part because the internal fields are not necessary for the filters and therefore could be hidden there too. Regards, --=20 Nicolas George --RqnqwLwXz/XASGr6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6ooRQGBoNzw0KnwPcZVLI8pNxgwFAmPZhQ8ACgkQcZVLI8pN xgwwgxAAm+24p28OOpAzCZB1WRyZIx6vFv77OY0L7w3jvj/Ax9IKydc9T2nKJFcN N9Rh8UVlmwdxNCN3UiyQq8hdWM1ckV2CBxXJOxT9MNN55TUGFonnHrH27hi1Fz0E GctCcJSqw98r33SurZdceSlRth20oJ34M1e4ZNoI1D6fFHZgMsZYT344a6Wfwwu+ 6TEpEYteCwrSaxAALzJ3nbO3yDgwfgQTTKKPOQi6YbQfpMcEKR26X9W/EevikzFI mOcJQyukrPS+NTt1Kk9UWxOKEbSHGHOtaqrqwy9Zzwbrc49uGbKCH7esoFPuxwkQ Pd9xIBjbZpvlbEHezdDa6BnozJAIgg6kyR98fQ16HpTrLnjE8ncPIGhXE9r2fB98 vstG9B1ECmW1yklI5i7DtouXh0htSOV7Hau+ZgD2vw8faSfibNPQ0s6TtNOWHNmK L5ePnqIcUSKg5Gmi7V6GKsfYQ6t8FuYuaZDcj8Kh7oC8KhGG6tChe8dlANZ+ZMKq Bc/h26EvzMQXQbFljrPoUcZn7kMZTcch8/A+0gsxlEs72NcPEr4obcaRhd3t262O 1qBj4V9Mtvm9FdT2CuhZ6ubdJLpjyrwEWKLZM2f6czoxD6ZNJ0M527BOHRiSlZ5K jRFAAgMQhazD6hoqJbK32vi5j4vKmI+t72jWqG0HYT+T8V0QCNM= =H/Zh -----END PGP SIGNATURE----- --RqnqwLwXz/XASGr6-- --===============7345420159595288695== 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". --===============7345420159595288695==--