From nobody Tue Aug 16 10:10:04 2022 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M6RjJ09q2z4Ydy9; Tue, 16 Aug 2022 10:10:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M6RjH6mnjz3y6k; Tue, 16 Aug 2022 10:10:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660644612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CZNNyY1Sw5VH5sm16RzXFyeI1gp5jvENorZOhRqmih4=; b=RMJ/mtNkOSaHMRQi2+zPfW4ny91miBh3aiFQKwXQqfsWlDQtbX+udTVoa9GnfdqjDwVgNr X46ucFt+qE/rq6AfUz84Mj0q7Kr4iY33G7G9lFp6zl8XW9UhzuOq3viRtQbBcCbEh260CJ MVnEwYQaN6o+wpEuzSnN+UNTivWvHsi/Qm3d9VP2wIE9uPjdYP/2Ho3eBrNTyU7d2sCUOW vR++/j7rKxI3d5s1qNPGlTLjS/g4ggYNYqaLqfrUUAskui/qzK/SqxhVRyZp40x3DRejmY yXiilCS8Hj7OeuJX6+XfVmn289fW6NM2CQQbBrb+AQhqgt0YcAYXy3bpBxos8A== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M6RjH4L23zvyC; Tue, 16 Aug 2022 10:10:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5548E46825; Tue, 16 Aug 2022 12:10:09 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_D1D1B96E-89FF-4547-B673-341F81D93C31"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: git: 402dbdd98acc - main - Adjust function definition in arm's mv_common.c to avoid clang 15 warning From: Dimitry Andric In-Reply-To: Date: Tue, 16 Aug 2022 12:10:04 +0200 Cc: Konstantin Belousov , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Message-Id: References: <202208151849.27FInHmh027652@gitrepo.freebsd.org> To: Jessica Clarke X-Mailer: Apple Mail (2.3696.120.41.1.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660644612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CZNNyY1Sw5VH5sm16RzXFyeI1gp5jvENorZOhRqmih4=; b=itoPXwyYWEcgMmD2aELH2aHCL2WokfdM2pQpz1300u5KZ0HaGLipTyap1LRSUHJfc9uCTq K4/4SNkrWZfYXPCdp3TLwwQHqvNQv+m8RWN66OHatiibAN5RWci9jr4xl4SctmxJVMhgZJ gXp1Oywsx3aR93tcXDAuPcsLA2PvKQqFMfFWK2tzgJeHbdMJCe2So8gIwUK2j6S/msu1Kh ZIFFYLXOy7tOlomV+kMTNWUD8d9iX8kWOW0x/fEPWC4whUv2ZI0Uz5oJeqMCS7Bhv2G1r2 iGTqjmqTFW4rewzBnGtmor6fgrnU0UHX6987jLuQib+Mv0nslDwQ68RNG1xLOQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660644612; a=rsa-sha256; cv=none; b=EDsUWibaZvsiv74GfxArQwFjFjopLx33+/j9da5iPdlZNA3jlz/8Mx2hqZjDFA/IawcrQv n447leyid6eXeZtKIXiZv7k4JCEmTVTYwoqhHpT08TQ7TPFEM+HTTEDvAALwuMGlQqcNYA C2oh7rjS2oQDE5nlq7Q86ktOU091l1YHflKpQebYJpvyFS3pcHtcKj63ZsnGUWUf3LgFQ9 MdU1VZ799o0DHQn3l+tRCGrbJWWNM+om5obSG8BAjzAYODQ2Xg9ZrKSK+Bf842KVHgMGhS DeRnJjFsac6bDJZytq+LIc8cz/uoK3KRgf5gv4tnkC4sg0MaInJjQZB5n81DKA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_D1D1B96E-89FF-4547-B673-341F81D93C31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 15 Aug 2022, at 23:23, Jessica Clarke wrote: >=20 > =3DOn 15 Aug 2022, at 22:07, Konstantin Belousov = wrote: >>=20 >> On Mon, Aug 15, 2022 at 06:49:17PM +0000, Dimitry Andric wrote: >>> The branch main has been updated by dim: >>>=20 >>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D402dbdd98acc7fa94d1d4cd01903e987= d2409336 >>>=20 >>> commit 402dbdd98acc7fa94d1d4cd01903e987d2409336 >>> Author: Dimitry Andric >>> AuthorDate: 2022-08-15 18:02:13 +0000 >>> Commit: Dimitry Andric >>> CommitDate: 2022-08-15 18:48:33 +0000 >>>=20 >>> Adjust function definition in arm's mv_common.c to avoid clang 15 = warning >>>=20 >>> With clang 15, the following -Werror warning is produced: >>>=20 >>> sys/arm/mv/mv_common.c:414:20: error: a function declaration = without a prototype is deprecated in all versions of C = [-Werror,-Wstrict-prototypes] >>> mv_check_soc_family() >>> ^ >>> void >>>=20 >>> This is because mv_check_soc_family() is declared with a (void) = argument >>> list, but defined with an empty argument list. Make the definition = match >>> the declaration. >>>=20 >>> MFC after: 3 days >>> --- >>> sys/arm/mv/mv_common.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>=20 >>> diff --git a/sys/arm/mv/mv_common.c b/sys/arm/mv/mv_common.c >>> index 6e1d12f8c7a7..c2e25c686583 100644 >>> --- a/sys/arm/mv/mv_common.c >>> +++ b/sys/arm/mv/mv_common.c >>> @@ -411,7 +411,7 @@ static int mv_win_cesa_attr_armadaxp(int = eng_sel) >>> } >>>=20 >>> enum soc_family >>> -mv_check_soc_family() >>> +mv_check_soc_family(void) >>> { >>> uint32_t dev, rev; >>>=20 >> I am actually curious about this and other commits. =46rom the = ISO/IEC 9899:2023 >> draft N3047, 6.7.6.3 Function declarators, clause 13: >>=20 >> For a function declarator without a parameter type list: the effect >> is as if it were declared with a parameter type list consisting of >> the keyword void. A function declarator provides a prototype for the >> function 177). >>=20 >> Then the note 177: >> This implies that a function definition without a parameter list >> provides a prototype, and that subsequent calls to that function in = the >> same translation unit are constrained not to provide any argument to = the >> function call. Thus a definition of a function without parameter list >> and one that has such a list consisting of the keyword void are fully >> equivalent. >>=20 >> And more, in the 6.9.1 Function definitions clause 13, there is an = example: >> typedef int F(void); // type F is "function with no parameters >> // returning int" >> int g() { /* ... */ } // RIGHT: g has type compatible with F >>=20 >> So why does clang enforce the warning? >=20 > I=E2=80=99m not sure why this is a warning; an empty parameter list in = a > function declaration that is part of a definition has always been the > same as (void) (unless you have K&R-style arguments, which the = compiler > can also see). C99 6.11.6 Function declarators does however say: >=20 >> 1 The use of function declarators with empty parentheses (not >> prototype-format parameter type declarators) is an obsolescent = feature. >=20 > So technically warning for pre-C23 is compliant with that, though a = bit > annoying in the definition case given the semantics have stayed the > same and been un-deprecated. Regardless, it=E2=80=99s probably best = practice to > be consistent and use (void) in the definitions so it matches any > declarations rather than have this be a special case that can differ. This changed upstream here: = https://github.com/llvm/llvm-project/commit/11da1b53d8cd3507959022cd790d5a= 7ad4573d94 where this warning got enabled for -Wstrict-prototypes. Another related change was: = https://github.com/llvm/llvm-project/commit/385e7df33046d7292612ee1e3ac00a= 59d8bc0441 Reading back some comments on the llvm IRC channel, I suppose another method could be to turn off -Wstrict-prototypes for clang >=3D 15, as it will already warn on problematic cases of call sites not matching existing declarations. For example: https://godbolt.org/z/7EPTYhKrY But I think it is better to have the definitions matching the declarations exactly. We should sweep through the whole tree and get rid of all K&R functions too. I believe Warner wanted to attempt that. -Dimitry --Apple-Mail=_D1D1B96E-89FF-4547-B673-341F81D93C31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYvts/AAKCRCwXqMKLiCW ozeoAKCuktPHCLz3cGCVqRdw/4iBPImzqACgr3RXuHsiSEFArYIcI9bv3w+wYFw= =4lT6 -----END PGP SIGNATURE----- --Apple-Mail=_D1D1B96E-89FF-4547-B673-341F81D93C31--