From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8E12A138334 for ; Sun, 9 Sep 2018 16:31:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3B960E09DD; Sun, 9 Sep 2018 16:31:08 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C4446E09BB for ; Sun, 9 Sep 2018 16:31:07 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id EF589335C5D; Sun, 9 Sep 2018 16:31:04 +0000 (UTC) Message-ID: <1536510660.863.9.camel@gentoo.org> Subject: Re: [gentoo-dev] Changing policy about -Werror From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Sun, 09 Sep 2018 18:31:00 +0200 In-Reply-To: <20180909143221.21d784d02f51623e8c57c545@gentoo.org> References: <20180909143221.21d784d02f51623e8c57c545@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-7+5ryoQt9OmbYivH5mOz" X-Mailer: Evolution 3.24.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Archives-Salt: 16ae2e28-04ab-4ae1-add0-522969739dee X-Archives-Hash: 02cc30cadcdaba496ecb85040f922f7a --=-7+5ryoQt9OmbYivH5mOz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2018-09-09 at 14:32 +0300, Andrew Savchenko wrote: > Hi! >=20 > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-w= error-compiler-flag-not-removed >=20 > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. >=20 > My point is that in *most* cases -Werror indeed should be removed, > because upstream rarely can keep up with all possible configure, > *FLAGS, compiler versions and arch combinations. But! In some cases > =E2=80=94 especially for security oriented software =E2=80=94 this flag m= ay be > pertain and may be kept at maintainer's discretion. >=20 > The rationale is that -Werror usually points to dangerous > situations like uninitialized variables, pointer type mismatch or > implicit function declaration (and much more) which may lead to > serious security implications. It may also point to a different coding style, user's flags (like clang's 'argument unused during X' warnings. Are you suggesting that upstream is going to detect all those situations and prevent them from occurring, or are you going to WONTFIX the resulting bugs? >=20 > So, if maintainer has enough manpower to support this flag, we > should allow to keep it. Of course if it will cause long-standing > troubles (e.g. bugs opened for a long time) QA should have power to > remove it or demand its removal. What you're saying basically boils down to 'it's fine that the package randomly fails to build if somebody will fix it'. However, some people actually use Gentoo on real systems and really prefer when things *build*. While resolving warnings etc. is usually a worthwhile goal, not at the cost of having users repeatedly hit failures, have to report bugs about them and wait for the maintainer to fix them. Not to mention that those fixes only work for new versions, and therefore this whole idea turns downgrading (however undesirable you might consider it) into a pointless effort of chasing old warnings. This is just another example of writing programs for a single toolchain, and adding more hacks every time someone tests with another one. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-7+5ryoQt9OmbYivH5mOz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAluVSsRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQoogxAA2ZeNdPJWdrfWjD5CpeqQg1d2vusLu6LItHk2iQqnvM4GWLN2irBuLEfv Tr5n+FXMSAjMYe5ovy/5aNCbd8wn50W8EXPL4yHlEt5UVYqprWx82c1F+hhS4l9l Vb/6+F9mWXE9Zvq6uGNFuU9g7DF6T/QEmFQSfwWEZ9aHSIWa/GQM7icNRfpXx3ZH Rx4UbxL70Ryf6DPjedecv3qdBnAMc+iAyT6VDmLmx75BQ7KQChhKYNR8aZy29p/c 0MWFeSAdIp+ot/s5QQ6lBBhcnAtX/0aabyiznPWbq0UZUTJJRTBEGH/aLHIKGho3 t4u3JGpnT/pXYLc5xMwJH2P50m5fPUn/Jsj1GtvfmlDarWzDCcUJeqCWDzxbP6Yp ePIg1TkDt3RD1S6FTIXtk/RrWbTxYfKKHgjHx+M+dYwQUj6bt7SGuZpu8cbHeBTc Q6l54msDhXU1+Vfcew38leQOWs2xFTnrG5Exq+LdOuK8YOtGSdLqmpCz1vAiGnBW 8EwneYyfMrArVMrjcP/wZSvZAlG0snJiOWlHCqH0lDtP3/MxWfAn46uJIiySAN5A tj9wF8Ao2Jf/jd+IKgSBE1Eyiw0QIMcgBaACleL8zsevGH4HCu4bzWVJi+E7Nyi0 S4nZoir2UX7Uv7Yw/t+S+eVntVGhKN+sfYqC4fDkCKlk8+BvJM4= =B4cp -----END PGP SIGNATURE----- --=-7+5ryoQt9OmbYivH5mOz--