From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by sourceware.org (Postfix) with ESMTPS id 7E0B2384F010 for ; Fri, 17 Jun 2022 01:14:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7E0B2384F010 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=anrddh.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=anrddh.me Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 52EF75C012A for ; Thu, 16 Jun 2022 21:14:46 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute3.internal (MEProxy); Thu, 16 Jun 2022 21:14:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anrddh.me; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1655428486; x=1655514886; bh=+A1kFMVvpz g4wFtbzV6cV4yftB0FyvYt8EW0uI1E0Zc=; b=TuiOyNtL9B3k/0GbQWAuM1LaIi MNiKv3Dlsu0X0miDTXETxdrfZXwk+rXv380BNy36dHhrmRxexgnb6Bi4tIoaHXTp VtH9VcyTkH1z0Ect2mNLqWnJm7q9MZ+oIeLz/GXOHkuu2f6WbJq4T3tyqll3NaLr YbdFEyr8uqX5ZYgEYGE2hLsvF2aPVsBDSJ+QAkGq07XNzi/xMUge6yjiqAogmfCq vxG9JQSiYQagNWnVvvbV9OcHYsJrcUJIx//WezYanjA1uHdO3g2EOgZfNgqBI+nB XV35yS1xQmjnsv2AGA8vOyTskinAY1XsbqqlAWKHwt3tV+W8R7NbICvMRkmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1655428486; x=1655514886; bh=+A1kFMVvpzg4wFtbzV6cV4yftB0F yvYt8EW0uI1E0Zc=; b=Uf7t1wftZ2PIVhtaIUgf/fpdl4C9sFBlfAd3SVidutCo yuItOD3bkA9Jmq1Uc2T+m4si5cV1JWgi+xLmSYwMx1Gxr5fc+mO34pG5m55OrZD5 BL/8f4Va00X/Ih665+oq7BeieMGfmNR3XDqYyciKtfvnWaIgIuShfWdhHBNbLoSv l5zCqWmAIgat3vgtKJWSQbtGqrEemH2ajQbtgDLAPV/yc6Gojx6TvjpD+YWs6vJL 2iwrSOvcU+7sK/HEAqNVX0kt7BMZHAQBM7TCMOd+zr0gC39Go5AvqPw5F/plhFm+ XJ5uisHjzHq0std9oIGpfAXI5Jb3zbdPAa7yCKpv1A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddvgedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehnihhruhguughhucetghgrrhifrghlfdcuoehmvges rghnrhguughhrdhmvgeqnecuggftrfgrthhtvghrnhepkeekkeegkedvvdegkeeufeeuke evgedtheeuvdfgueeuvdduffejveejieelffdtnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepmhgvsegrnhhrugguhhdrmhgv X-ME-Proxy: Feedback-ID: iebe9444d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 20B35BC0073; Thu, 16 Jun 2022 21:14:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-712-gb9e94258b0-fm-20220610.001-gb9e94258 Mime-Version: 1.0 Message-Id: <7be95d6d-c75a-40dc-9a92-bc0be08bbddc@www.fastmail.com> In-Reply-To: <60377b43-444e-421b-afaa-85fccbf331ee@www.fastmail.com> References: <60377b43-444e-421b-afaa-85fccbf331ee@www.fastmail.com> Date: Thu, 16 Jun 2022 21:14:25 -0400 From: "Aniruddh Agarwal" To: gcc@gcc.gnu.org Subject: Re: [RFC] Warnings for cases where int promotion is unexpected and may cause bugs Content-Type: text/plain X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2022 01:14:47 -0000 Apologies, I didn't realize that my mail client doesn't auto-wrap. Please find a wrapped copy of my original message below my signature. -Ani On Thu, Jun 16, 2022, at 9:11 PM, Aniruddh Agarwal wrote: > Hello, > > A colleague patched a prod-critical bug today caused by an overlooked > implicit int promotion when adding uint8_t's. g++ (v12.1) doesn't > report any warnings for it with all combinations of warnings flags that > I've tried, so I thought I'd ask if: > > - there *is* already some combination of warning flags that *would* > report a warning for this code > > - if not, then if there's any interest in work (which of course I'd be > happy to contribute to) on detecting and flagging this sort of problem. > > A (much simplified) example which illustrates the bug: > #+BEGIN_SRC cpp > #include > > using std::uint8_t; > > bool foo(uint8_t a, uint8_t b, uint8_t c) { > return (a + b) == c; > } > #+END_SRC > > Here's the problem: the expectation here is that "a + b" will have type > uint8_t. So, for example it expects "foo(200, 200, 144)" to return > "true". > > In reality, "a + b" implicitly promotes to an "int" and so we end up > comparing 400 and 144, which returns false. > > (Side note, not immediately relevant: I'm not sure if this ends up > being equivalent to calling something like a "bool operator==(int, > uint8_t)" or if the RHS is also implicitly promoted to an int before > the comparison. This is irrelevant for the immediate example because > the end result is the same in either case, but I would appreciate it if > someone can shed light on what the standard has to say on this for > future reference.) > > A correct implementation of the expected behavior is instead therefore: > #+BEGIN_SRC cpp > #include > > using std::uint8_t; > > bool foo(uint8_t a, uint8_t b, uint8_t c) { > return static_cast(a + b) == c; > } > #+END_SRC > > Does anyone else find this very surprising, and as I asked above, does > it seem worthwhile to try to flag code like in the first snippet? I > don't know what gcc's general policy on trying to warn about code like > this is. The new theoretical warning would be in the spirit of > -Wconversion. > > -Ani