From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93340 invoked by alias); 23 Feb 2018 21:58:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 93324 invoked by uid 89); 23 Feb 2018 21:58:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Casting, Hx-languages-length:2250, consciously X-HELO: mail-oi0-f65.google.com Received: from mail-oi0-f65.google.com (HELO mail-oi0-f65.google.com) (209.85.218.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Feb 2018 21:58:56 +0000 Received: by mail-oi0-f65.google.com with SMTP id c83so6875134oib.1 for ; Fri, 23 Feb 2018 13:58:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gcdqQl1l3ABUFuz6Iy72i8LPBDCVuhHKAOrwJiKZ68s=; b=LO3F9gDJgHE0z8iCh9KCVSrWpTvZlPlhhVZi5+vZnlOFwqaZygKxZxte18dZnrajZ7 hXIMdJCfgU/3Ksi1uQKaohgbP6bhu5LIE1FgKEWEi/or6mNswZ4w/a3R2zYlqE9ybHUH FGAYkkJyORxel01UcZctRqLfyNrCK+NQiOC+yJ6smiCuA48NN2VimGS9LeDGlbw4S3S3 HOqe37HNo7bNpUp4JQcUD1VxIxlrpP4HPQUc+8EO4aSKMG6O7ar2sWvPp0XHi7aCEGN8 G9mC2HyfZH/Y7d2rYysZLtAZfyGLdBCyMqPEhBdLcAJejst2RzeiqNI8Wo2K5aZ9HoAm 6mgg== X-Gm-Message-State: APf1xPBp0bRO8XUG/XI4KPDOYmC/mcUAR8bmFGYqr8/0itVDPrxnRfva R1VNFIL/e7SYgoOV6XC0Nek= X-Google-Smtp-Source: AG47ELt0mhfOollzJpOk0ZpulPL5mnNP38YAznjpa23NqPccTSQD0kebBFc+cq6yRRRfMTxFXICoLQ== X-Received: by 10.202.234.135 with SMTP id i129mr1902234oih.291.1519423135169; Fri, 23 Feb 2018 13:58:55 -0800 (PST) Received: from localhost.localdomain (75-171-228-29.hlrn.qwest.net. [75.171.228.29]) by smtp.gmail.com with ESMTPSA id g50sm1676583otd.22.2018.02.23.13.58.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 13:58:54 -0800 (PST) Subject: Re: [PATCH] Fix bogus function cast warning for functions with common arg subset To: Siddhesh Poyarekar , Richard Biener , gcc-patches@gcc.gnu.org, David Malcolm References: <20180223034045.26231-1-siddhesh@sourceware.org> <1519401043.2913.34.camel@redhat.com> <6b766ed9-1da3-7712-1d0c-1a50f2c44d38@sourceware.org> <4dfc6ad1-f3a8-e4d5-0629-65d8becfd50c@sourceware.org> From: Martin Sebor Message-ID: <057fb49c-4b96-5683-6d32-5cec022c8078@gmail.com> Date: Fri, 23 Feb 2018 21:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4dfc6ad1-f3a8-e4d5-0629-65d8becfd50c@sourceware.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg01358.txt.bz2 On 02/23/2018 01:32 PM, Siddhesh Poyarekar wrote: > On Saturday 24 February 2018 01:32 AM, Martin Sebor wrote: >> Casting the address of a function that takes one or more arguments >> to one that takes fewer is unsafe because when the pointer is used >> to call the function the extra arguments have indeterminate values. >> (This is also why void(*)(void) as a wildcard was a poor choice: >> because it's only safe when it's an exact match.) >> >> Casting in the opposite direction (fewer arguments to more) can >> also lead to bugs under ABIs where the callee is responsible for >> restoring the frame pointer. > > I completely agree about the safety aspect of it, but my argument is > about user experience, not safety. We are after all talking about > explicit casts, i.e. cast decisions that users have consciously made. I agree. That was also my first comment on the feature when it was first proposed: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00275.html >> The intent behind the warning is to help find instances of these >> conversions that are unsafe and to drive improvements to code and >> get it to adopt a single common wildcard. The current choice >> isn't ideal but expanding it even further would compromise >> the goal of the warning even more. > > While varargs may solve a lot of these problems, the best viable > solution or cases where such casts are necessary seems to be to switch > off the warning, which kinda defeats the goal anyway. IMO we're better > off making the warnings as less intrusive as possible to begin with and > then gradually make them more aggressive. In my mind that would be a perfectly reasonable approach. A variation on it might be to leave a new warning disabled in the first release, then include it in -Wextra the next release, and finally put it in -Wall. Unfortunately, in reality this rarely happens. Most warnings stay wherever they land when they're first added and only few are ever tightened up. Most also stay the same for many releases. (IME, it's not a fun or glamorous job to do the work it takes to turn on a disabled warning, or to tighten up an existing one and deal with the fallout.) Martin