From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Bruno Haible Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: New warnings on emacs-26 branch with gcc 8.2.0 Date: Sun, 19 Aug 2018 10:40:55 +0200 Message-ID: <10249563.cWOUyIUhOo@omega> References: <86a7q0ai2z.fsf@gmail.com> <2510628.alnMaqBdeU@omega> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: blaine.gmane.org 1534667968 30682 195.159.176.226 (19 Aug 2018 08:39:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Aug 2018 08:39:28 +0000 (UTC) User-Agent: KMail/5.1.3 (Linux/4.4.0-130-generic; KDE/5.18.0; x86_64; ; ) Cc: bug-gnulib@gnu.org, Eli Zaretskii , Paul Eggert , andrewjmoreton@gmail.com, Emacs developers To: Yuri Khan Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Sun Aug 19 10:39:24 2018 Return-path: Envelope-to: gnu-bug-gnulib@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1frJF5-0007ua-EB for gnu-bug-gnulib@m.gmane.org; Sun, 19 Aug 2018 10:39:23 +0200 Original-Received: from localhost ([::1]:42036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frJHB-0000bS-T6 for gnu-bug-gnulib@m.gmane.org; Sun, 19 Aug 2018 04:41:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frJGp-0000aF-F4 for bug-gnulib@gnu.org; Sun, 19 Aug 2018 04:41:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frJGo-0004Sb-PV for bug-gnulib@gnu.org; Sun, 19 Aug 2018 04:41:11 -0400 Original-Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::3]:26703) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1frJGn-0004Rk-61; Sun, 19 Aug 2018 04:41:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1534668066; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=tvlmpML9aYQFQ1qw+mTLi9el/i9w8RE9yM9XlhzwLE0=; b=oqmfo81klFjH6sNflEOM82bddvAar5nZNlkbpNjUtdTnL+v80dcOqdwif9iXz5JMVd vVk4A+QiKnAQlYZkzn1/BPfxV/yngb3nzUTCfvFDBZgPmoMZtsBW0sn3xvmqZTXGNNiY qMVGzylKPmZPLuWGKDdPzA0A1R5IbsRdBCrNeiA7M8ntXRUin47rFEfQ6sJpf+6V6eW2 Mm5Pb8dB/qOh1MpQej8+vakUfKBm75CmCEifgxw2LEkzSyxeTUbEVF9Atyr25Zpg1zLt 8nEyPqKQDW4As6SSf9YFwlwFtzRFz8A8zWAKNv+BvNzn4/uWJKgSHkxftksl9f5PkiAQ fbPw== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf9yfs=" X-RZG-CLASS-ID: mo00 Original-Received: from bruno.haible.de by smtp.strato.de (RZmta 43.18 DYNA|AUTH) with ESMTPSA id n0457au7J8euMDz (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 19 Aug 2018 10:40:56 +0200 (CEST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::3 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Original-Sender: "bug-gnulib" Xref: news.gmane.org gmane.comp.lib.gnulib.bugs:39234 gmane.emacs.devel:228675 Archived-At: Yuri Khan wrote: > > Indeed, casting through (void *) or (void (*) (void)) avoids the > > warning. > > I seem to remember C does not guarantee that pointers to functions > must survive casting through void*. Yes, on some old architectures like Windows 3.1 a function pointer and a 'void *' had different representations. But the fact that 'dlsym' has a 'void *' return value proves that this is not an issue nowadays any more. > It does for casting between > function pointer types. So casting through (void (*)(void)) is going > to be more portable. No. GCC sometimes generates a __builtin_trap (a kind of undebuggable abort()) when you cast function pointers in an incompatible way. (*) So, I would avoid this. Bruno (*) The precise conditions I know of are: 1. take the address of a declared function, 2. cast it to an incompatible function type, 3. invoke it with arguments according to this function type. But maybe there are other situations where the same thing occurs or might occur in the future? Who knows...