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 726FF4CE7C for ; Wed, 31 Dec 2025 14:10:44 +0000 (UTC) Authentication-Results: ffbox; dkim=fail (body hash mismatch (got b'JPprqfrKt5mUHywrabT9q+CSR/gwzkoG8h1DTK2ZiGA=', expected b'AJSTuD67SlbgaYr9iKPDBzBI7+z2r7c1mej/IA3PbD8=')) header.d=niedermayer.cc header.a=rsa-sha256 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ffmpeg.org; i=@ffmpeg.org; q=dns/txt; s=mail; t=1767190225; h=date : to : message-id : references : mime-version : in-reply-to : reply-to : subject : list-id : list-archive : list-archive : list-help : list-owner : list-post : list-subscribe : list-unsubscribe : from : cc : content-type : from; bh=Z3OMPxelYgY7+hRC1z9VKOOgrvcMd1iJzDpxsQbN1k8=; b=v4rEKfZ9WcoVjuBTPZMgBlGy9Ni/k+0bFKpkXegVWKt3NJnBifeX5T7BdVt09LL1mNZqN XtAzbRy7uloAcG8OneX8kgRAlDjUmp70EMnpfLA2X7Gag/b7aydmOUcSrMVWwP3lXbrNe0R NMUFCjD2ZQMEtde4N6Y9bsTzj9YHiN8EbHERJePWP4zjxnj69HDFCNa4YB1JqTbaHc1lT3P sw1yTdKKkIU6y/hMYOW3ae2yg7bD9FEhnJxMaBSC2B5LYpBdEkiDUQYAQfuKjQu4IHHBK+T xmz1gD7DlBby4D6KxuXyMNw8V9TFTqDzf9lK2g9MgIqmwO3yJikp7/1ktZ3g== Received: from [172.20.0.4] (unknown [172.20.0.4]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id BC8AD690C5F; Wed, 31 Dec 2025 16:10:25 +0200 (EET) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=ffmpeg.org; s=arc; t=1767190209; b=iXge6JNRU/AoTpiOr0t/QzlgSQMIHPzm9iEiuKARZMx5tO6LXqc5bn1bFrGJrW7lSv8wr dSUQIQOwRbbXGt9xN2HrmwR+ZkJ5R8Az5luymKEN66+TmzDzzMuPAgvkLsn+IqhWrAhQA5b abImes1zs/SIAHY3kdjMneKrYX2hglKki29jcEDKPDj6GKFbsghpBGEX9i/60vvRwFmRyY/ 5oSuQhSwerZVXoUb7jmjUeROAj3nwyysJe2cdGpNvWMDWibZq6X+GDJBIl5o/dtzNSqczwS 2C9fm/x32+JTx3oWX71Ul8geF7FJplHYGx/m7HNhv3XbVR+D9Rna5zPJlVxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=ffmpeg.org; s=arc; t=1767190209; h=from : sender : reply-to : subject : date : message-id : to : cc : mime-version : content-type : content-transfer-encoding : content-id : content-description : resent-date : resent-from : resent-sender : resent-to : resent-cc : resent-message-id : in-reply-to : references : list-id : list-help : list-unsubscribe : list-subscribe : list-post : list-owner : list-archive; bh=JPprqfrKt5mUHywrabT9q+CSR/gwzkoG8h1DTK2ZiGA=; b=Z5ndq6EjZr4QUXcFQjAqgXmly/hrk1sQFN/WhYjmW31BWaVmlhG6JU+NmjkwUn5nSvSj+ 1KHHKwZu+qk3nwW6hFbPMJ0+at+V+m/hfeatdDzT4BQqyR9IZtIWwDULmBUwr2b3j1FZATg Y1GeHQrj+DIo0t7Ze2Dg5yC1loniUY0ZhxOvARoFj4MW0oCbtNELIdmbJiCRH41swBcKTfQ XxQW97Aydz5wnPteH/Jj9NFvFkPg09faim/IfAFR7r9pnItQOl6DzX5K4z7kAQ7Omlh3Exn iwnKjETRTLUyVn0JPMCDxbbgt87qDK4mFB1Z3+K9bgcglUd5ffdjQKejxwcw== ARC-Authentication-Results: i=1; ffmpeg.org; dkim=pass header.d=niedermayer.cc; arc=none; dmarc=none Authentication-Results: ffmpeg.org; dkim=pass header.d=niedermayer.cc; arc=none (Message is not ARC signed); dmarc=none Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 6E8A3690A03 for ; Wed, 31 Dec 2025 16:09:56 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id A02FD44283 for ; Wed, 31 Dec 2025 14:09:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1767190195; 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=AJSTuD67SlbgaYr9iKPDBzBI7+z2r7c1mej/IA3PbD8=; b=NwlMg1Ge4rWzCpqldEnq8wbHg5tQgObDwvyrqul8cmhLoRgfC0yAKT8ItunKl9Zqm8Nvbl gCNiGsNcmkvBmddif0zp0lFjgZPS/VOZQr/c+GPsP17La4bJfOa7zKf1RntQ244FuH9QPO GhqAkIXLzSZXx56x52D1RTvaCyHpudwAofx9AVqCBvMH8OEMl1jQ2bmL0fYejo0I+mnJQW 6Kf+jKytm7I7PknoQKvni498QwqVjVYqcS92v1idTYt2SZGK4lzv3GrsvStsM+pwd4DAb7 i1OBGhx1oL2tVY6tj3muo3KKVs6MLnzGCizH4d9rv4ivingZHyDUYEo5b7GBpQ== Date: Wed, 31 Dec 2025 15:09:54 +0100 To: FFmpeg development discussions and patches Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc X-GND-State: clean X-GND-Score: -85 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdekfedutdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdludehmdenucfjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofhitghhrggvlhcupfhivgguvghrmhgrhigvrhcuoehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgeqnecuggftrfgrthhtvghrnhepleekgefgffeiudefjeeuffejudehtddtudeltdehveevvedtieeulefhtdeutdeknecukfhppeeguddrieeirdeiiedrhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieeirdehtddphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtpdhqihgupeettddvhfffgeegvdekfedpmhhouggvpehsmhhtphhouhhtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepfhhfmhhpvghgqdguvghvvghlsehffhhmphgvghdrohhrgh Message-ID-Hash: EUSYXFQPI2TRZR26B2NO4GEY33UXNX63 X-Message-ID-Hash: EUSYXFQPI2TRZR26B2NO4GEY33UXNX63 X-MailFrom: SRS0=4D86=7F=niedermayer.cc=michael@ffmpeg.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-ffmpeg-devel.ffmpeg.org-0; header-match-ffmpeg-devel.ffmpeg.org-1; header-match-ffmpeg-devel.ffmpeg.org-2; header-match-ffmpeg-devel.ffmpeg.org-3; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Reply-To: FFmpeg development discussions and patches Subject: [FFmpeg-devel] Re: [FFFjo] [FFmpeg/FFmpeg] -fshort-enum breaks ABI compatibility and enum/int pointer conversions (Issue #21289) List-Id: FFmpeg development discussions and patches Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Michael Niedermayer via ffmpeg-devel Cc: Michael Niedermayer Content-Type: multipart/mixed; boundary="===============1313791057829609174==" Archived-At: List-Archive: List-Post: --===============1313791057829609174== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lzJGC5cyUyiLTgJk" Content-Disposition: inline --lzJGC5cyUyiLTgJk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Wed, Dec 31, 2025 at 10:31:30AM +0800, Zhao Zhili via ffmpeg-devel wrote: >=20 >=20 > > On Dec 31, 2025, at 04:44, Michael Niedermayer via ffmpeg-devel wrote: > >=20 > > Hi Zhao > >=20 > > On Tue, Dec 30, 2025 at 12:46:24AM +0800, Zhao Zhili via ffmpeg-devel w= rote: > >>=20 > >>=20 > >>> On Dec 24, 2025, at 11:30, nyh163925 wrote: > >>>=20 > >>>=20 > >>> Hello FFmpeg community, I am from Xiaomi Vela, and we have built the = Vela multimedia system using FFmpeg. Thank you for the invaluable work you = do=E2=80=94FFmpeg is the cornerstone of many of our modules. > >>>=20 > >>> ISSUE: -fshort-enum ABI problem > >>>=20 > >>> In the process of application, we found that some embedded platforms = (such as ARM Cortex-m) have enabled -fshort-enum optimization by default in= their compilers, which leads to ABI in the cross passing of some enum * an= d int * in FFmpeg. For example, when passing enum AVSampleFormat * as int *= in ff_det_common_fformats_for_list2(), it will cause check_fformat() error. > >>>=20 > >>> Context > >>>=20 > >>> C language Standard undefined behavior: > >>> The underlying type and size of an enum are implementation-defined. M= any toolchains can use the smallest integer type that fits the values (e.g.= , with -fshort-enums), so sizeof(enum) can be less than sizeof(int), and al= ignment may differ. > >>> Casting enum* to int* and accessing through the int pointer runs into= strict-aliasing and effective-type rules; it is not portable and may be un= defined. > >>>=20 > >>> FFmpeg defaults to the equality of sizeof(enum) and sizeof(int): > >>> We have seen code patterns that implicitly assume =E2=80=9Cenum is a = 4-byte int=E2=80=9D and interchange enum* with int*. Typical examples inclu= de: > >>>=20 > >>> BufferSinkContext { > >>> enum AVSampleFormat *sample_formats > >>> ... > >>> } > >>>=20 > >>> int ff_set_common_formats_from_list2(const AVFilterContext *ctx, > >>> AVFilterFormatsConfig **cfg_in, > >>> AVFilterFormatsConfig **cfg_out, > >>> const int *fmts) > >>>=20 > >>> static int asink_query_formats(const AVFilterContext *ctx, > >>> AVFilterFormatsConfig **cfg_in, > >>> AVFilterFormatsConfig **cfg_out) > >>> { > >>> const BufferSinkContext *buf =3D ctx->priv; > >>> if (buf->nb_sample_formats) { > >>> ret =3D ff_set_common_formats_from_list2(ctx, cfg_in, cfg_out, = buf->sample_formats); > >>> if (ret < 0) > >>> return ret; > >>> } > >>> ... > >>> } > >>> We are facing a conflict dilemma: > >>> We found that many ARM-based embedded compilers and third-party libra= ries default to -fshort-enums, which conflicts with FFmpeg's ABI (compiled = with -fno-short-enums). However, if we enable the '-fshort-enums' in FFMPEG= , the above ABI causes format negotiation and matching failures in our modu= les. > >>> Proposed paths forward > >>>=20 > >>> Change =E2=80=9Cassume 4 bytes=E2=80=9D to =E2=80=9Cforce 4 bytes=E2= =80=9D. > >>> Adopt a fixed 32-bit representation for enums at API/ABI boundaries > >>> vulkan for example, uses *_MAX_ENUM =3D 0x7FFFFFFF as last value for = each enum, to avoid any and all problems with size > >>>=20 > >>> Stop assuming sizeof(enum) =3D=3D 4. > >>> Gradually fix code to avoid enum* =E2=86=94 int* aliasing; use value-= level conversions or memcpy where needed. > >>> Pros: preserves the size benefits where compilers choose smaller enum= s. > >>> Cons: requires auditing and incremental code changes. > >>>=20 > >>> We=E2=80=99re seeking the community=E2=80=99s guidance on which direc= tion is preferable for FFmpeg: Should we standardize on a fixed 32-bit enum= representation for ABI stability? Or should we remove the =E2=80=9Cenum = =3D=3D int=E2=80=9D assumption and accept smaller enums, with code cleanup = to avoid aliasing and stride errors? > >>> We=E2=80=99re ready to contribute patches in the direction the projec= t prefers and to align with FFmpeg=E2=80=99s coding guidelines. Thanks agai= n for your time and feedback. > >>>=20 > >>=20 > >> I think the issue is common and better be discussed on the mailing lis= t. It's a big decision. > >=20 > > The way we mix enums and int currently is not good, so iam in favor of = some > > solution. > > Which solution, i dont have a strong oppinion about. >=20 > Once set AV_SAMPLE_FMT_MAX =3D 0x7FFFFFFF, it=E2=80=99s hard to revert an= d choose > another solution. >=20 > If we are unable to decide on which solution to adopt for the moment, can= we start > by fixing some internal code issues caused by short-enum first? yes i suspect AVOption access to type enum will be the bulk of what needs fixing thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopp= ed=20 leading them. They have either lost confidence that you can help or conclud= ed=20 you do not care. Either case is a failure of leadership. - Colin Powell --lzJGC5cyUyiLTgJk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaVUuqAAKCRBhHseHBAsP q5zMAJ9ztjWXuQgDHnXoXmT4C2ReeIPkCwCcCF2YRVdqLNE3fcwow60NxV0CJ+g= =DEvE -----END PGP SIGNATURE----- --lzJGC5cyUyiLTgJk-- --===============1313791057829609174== 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 To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org --===============1313791057829609174==--