From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cventin.lip.ens-lyon.fr (cventin.lip.ens-lyon.fr [140.77.13.17]) by sourceware.org (Postfix) with ESMTPS id 0C28A384A87E for ; Thu, 8 Oct 2020 13:52:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0C28A384A87E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vinc17.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=vincent@vinc17.net Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.94) (envelope-from ) id 1kQWL4-00CeVR-KN; Thu, 08 Oct 2020 15:52:10 +0200 Date: Thu, 8 Oct 2020 15:52:10 +0200 From: Vincent Lefevre To: Alejandro Colomar Cc: "Michael Kerrisk (man-pages)" , linux-man@vger.kernel.org, libc-alpha@sourceware.org, gcc@gcc.gnu.org Subject: Re: [PATCH v2 1/2] system_data_types.7: Add 'void *' Message-ID: <20201008135210.GA2956488@cventin.lip.ens-lyon.fr> Mail-Followup-To: Alejandro Colomar , "Michael Kerrisk (man-pages)" , linux-man@vger.kernel.org, libc-alpha@sourceware.org, gcc@gcc.gnu.org References: <41affebd-3354-9420-0048-bffd14535e95@gmail.com> <20201001154946.104626-2-colomar.6.4.3@gmail.com> <41ab7ed9-3ce0-f8ad-38f4-c4bbeca138f8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41ab7ed9-3ce0-f8ad-38f4-c4bbeca138f8@gmail.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.14.3+64 (75be2b07) vl-127292 (2020-06-15) X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 13:52:15 -0000 On 2020-10-01 18:55:04 +0200, Alejandro Colomar via Gcc wrote: > On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote: > > > +According to the C language standard, > > > +a pointer to any object type may be converted to a pointer to > > > +.I void > > > +and back. > > > +POSIX further requires that any pointer, > > > +including pointers to functions, > > > +may be converted to a pointer to > > > +.I void > > > +and back. > > I know you are correct about POSIX, but which part of the > > standard did you find this information in? The only > > reference that I find in POSIX is the dlsym() spec. Is it > > covered also somewhere else in the standrd? [...] > I've bean searching, and dlsym is the only one: [...] > The most explicit paragraph in dlsym is the following: > > [[ > Note that conversion from a void * pointer to a function pointer as in: > > fptr = (int (*)(int))dlsym(handle, "my_function"); > > is not defined by the ISO C standard. > This standard requires this conversion to work correctly > on conforming implementations. > ]] I think that "this conversion" applies only to the dlsym context, and the conversion isn't defined in general. Imagine that the void * pointer to function pointer conversion requires the compiler to generate additional code. The compiler may be able to detect that dlsym will not be used in some contexts (e.g. because of always false condition) and do not generate such additional code, making the conversion to have undefined behavior. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)