[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141209000614.GL4574@brightrain.aerifal.cx>
Date: Mon, 8 Dec 2014 19:06:14 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: pthread_equal
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 <left-parenthesis> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
