From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6702 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthread_equal Date: Mon, 8 Dec 2014 19:06:14 -0500 Message-ID: <20141209000614.GL4574@brightrain.aerifal.cx> References: <1418049745.15892.10.camel@posteo.de> <20141208145604.GC4574@brightrain.aerifal.cx> <1418055521.15892.16.camel@posteo.de> <20141208162509.GI4574@brightrain.aerifal.cx> <1418073109.2353.10.camel@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1418083595 24503 80.91.229.3 (9 Dec 2014 00:06:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2014 00:06:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6715-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 09 01:06:31 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xy8Jw-0003He-CD for gllmg-musl@m.gmane.org; Tue, 09 Dec 2014 01:06:28 +0100 Original-Received: (qmail 21685 invoked by uid 550); 9 Dec 2014 00:06:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21677 invoked from network); 9 Dec 2014 00:06:26 -0000 Content-Disposition: inline In-Reply-To: <1418073109.2353.10.camel@posteo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6702 Archived-At: On Mon, Dec 08, 2014 at 10:11:49PM +0100, Jörg Krause wrote: > On Mo, 2014-12-08 at 11:25 -0500, Rich Felker wrote: > > On Mon, Dec 08, 2014 at 05:18:41PM +0100, Jörg Krause wrote: > > > On Mo, 2014-12-08 at 09:56 -0500, Rich Felker wrote: > > > > On Mon, Dec 08, 2014 at 03:42:25PM +0100, Jörg Krause wrote: > > > > > Why does musl declares pthread_equal both as macro and as function? > > > > > > > > C and POSIX allow any of their standard functions to be provided as > > > > macros too, but the function definition must always be provided. The > > > > reason I put the macro in musl is simply that it's easy to do and > > > > gives better code (trivial inline comparison rather than spilling all > > > > registers and making a function call) and it's not something where the > > > > implementation could change or need to change. > > > > > > I see! The problem was, that MPD (Music Player Daemon, implemented in C > > > ++) for instance used ::pthread_equal(id, other_id) which did not build > > > with musl because of the macro expansion. > > > > > > The maintainer removed the namespace operator to get it work with musl: > > > http://git.musicpd.org/cgit/master/mpd.git/commit/?h=v0.18.x&id=d8fc2db910a11dbbba53ba7ecf96d0e32a081076 > > > > I see. > > > > For the standard C headers, the C++ versions are supposed to omit the > > macros that the C versions might offer. However, there's no such rule > > for POSIX headers since there's no formal spec for interaction of C++ > > and POSIX at all. Perhaps it would be useful to take the same approach > > and suppress such macros if __cplusplus is defined, even in the POSIX > > headers? But I think from an application portability perspective, they > > should either use #undef or parens, i.e. (::pthread_equal)(id1,id2), > > instead of assuming there is no macro. > > From an application developer point of view I would look at the POSIX > specification which says pthread_equal is a function defined as: > int pthread_equal(pthread_t t1, pthread_t t2) It's not specified on a per-header/per-function basis but globally, in XSH 2.1.1 Use and Implementation of Functions, item 2: Any function declared in a header may also be implemented as a macro defined in the header, so a function should not be declared explicitly if its header is included. Any macro definition of a function can be suppressed locally by enclosing the name of the function in parentheses, because the name is then not followed by the that indicates expansion of a macro function name. For the same syntactic reason, it is permitted to take the address of a function even if it is also defined as a macro. The use of the C-language #undef construct to remove any such macro definition shall also ensure that an actual function is referred to. Source: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_01_01 This is analogous to what the C standard specifies for the standard C functions. > I also proposed the solution with the parentesis. But in my opinion it > is a little bit confusing for an application developer to assume a > function specified by POSIX may be implemented as a macro. I agree however that this is counter-intuitive for C++ programmers, so we should probably go through and suppress the macros for C++. There probably aren't many to do anyway. We can probably get that changed in this release cycle, especially if anyone is willing to help make a list of them or a proposed patch to add #ifndef __cplusplus around them. Rich