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 31061384F010 for ; Fri, 17 Jun 2022 01:11:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 31061384F010 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 45B555C010E for ; Thu, 16 Jun 2022 21:11:25 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute3.internal (MEProxy); Thu, 16 Jun 2022 21:11:25 -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:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm1; t= 1655428285; x=1655514685; bh=KnqgB4EyQxKljaQOCvJT72RiOMSc6Gw1zot dtljQNlc=; b=ZXKzceuw9NOKd3bN3TDiO+h0ew0zQy+XE9xkIBfP6ri+KGRzjze rdTQTDV+h9WF6EZuX1vIDS0Q0niAX7MwAAy+LLePknBLl3vptYvUGKVzmjKMj3Pc /uz7MVYR8BidEYS8nLG5M9ayKGkX4DCclCUU6Nd8WeCtHXUT4fFyzCH3qQ+uGd7C HP3VitLBOLD4RaO4EJbDsr6oRBIdJq7xoeb/bvfnuD6DZiCB0MaGWFVBN8jkkCsD pyQknhSd439obJgXHlrsPeooePmdJDlyRFBy4PFxCv54rcXmsH96Y6e8zeDYMFzj S5HPddjorl2k2MmqDcTYohdNHa5H5pCrvRA== 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:message-id:mime-version :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=1655428285; x= 1655514685; bh=KnqgB4EyQxKljaQOCvJT72RiOMSc6Gw1zotdtljQNlc=; b=W Yi6jnGV6bdt1ROzq0YIo7a2Gj8AZO9GGw4P5AWOsyonRHTSfVXsni6kr48D9zEg5 8n8qJs7Xi2JP9swQfoQTD5z2uOt/jiq+vhHWGjgUDEar+wmMzlreLWcxIoGu0uE5 e+PB3bm/oPpc5Gw8ECBm7qH0BuluO4bpoGZ4txqB+ticyYxIIuRMkB/YboODUEcr IWVTkhUHKHWgpuUfFW1xaBWhPOH97LxD2tjHpupdim6c1Im9k57xPKmEScebiYVT A/ayuS6iccvTPQd+Ze2wd7HZFlYuq8JUJSrTTGgSbdiNKfJTUViMWYprGtYxAvop KSFZQ7RfW3Zjp78FEt5SA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddvgedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedftehnihhruhguughhucetghgrrhifrghlfdcuoehmvgesrghn rhguughhrdhmvgeqnecuggftrfgrthhtvghrnhepgedvhfeiudfgueeufeeugeefhedule ejudetueehieeuvedtieetteejhffhfeeunecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepmhgvsegrnhhrugguhhdrmhgv X-ME-Proxy: Feedback-ID: iebe9444d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id DEF59BC0073; Thu, 16 Jun 2022 21:11:24 -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: <60377b43-444e-421b-afaa-85fccbf331ee@www.fastmail.com> Date: Thu, 16 Jun 2022 21:11:04 -0400 From: "Aniruddh Agarwal" To: gcc@gcc.gnu.org Subject: [RFC] Warnings for cases where int promotion is unexpected and may cause bugs Content-Type: text/plain X-Spam-Status: No, score=-2.5 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:11:29 -0000 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