* pthread_equal @ 2014-12-08 14:42 Jörg Krause 2014-12-08 14:56 ` pthread_equal Rich Felker 0 siblings, 1 reply; 9+ messages in thread From: Jörg Krause @ 2014-12-08 14:42 UTC (permalink / raw) To: musl Why does musl declares pthread_equal both as macro and as function? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: pthread_equal 2014-12-08 14:42 pthread_equal Jörg Krause @ 2014-12-08 14:56 ` Rich Felker 2014-12-08 16:18 ` pthread_equal Jörg Krause 0 siblings, 1 reply; 9+ messages in thread From: Rich Felker @ 2014-12-08 14:56 UTC (permalink / raw) To: musl 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. Rich ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: pthread_equal 2014-12-08 14:56 ` pthread_equal Rich Felker @ 2014-12-08 16:18 ` Jörg Krause 2014-12-08 16:25 ` pthread_equal Rich Felker 0 siblings, 1 reply; 9+ messages in thread From: Jörg Krause @ 2014-12-08 16:18 UTC (permalink / raw) To: musl 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. > > Rich 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 Jörg ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: pthread_equal 2014-12-08 16:18 ` pthread_equal Jörg Krause @ 2014-12-08 16:25 ` Rich Felker 2014-12-08 21:11 ` pthread_equal Jörg Krause 0 siblings, 1 reply; 9+ messages in thread From: Rich Felker @ 2014-12-08 16:25 UTC (permalink / raw) To: musl 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. Rich ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: pthread_equal 2014-12-08 16:25 ` pthread_equal Rich Felker @ 2014-12-08 21:11 ` Jörg Krause 2014-12-09 0:06 ` pthread_equal Rich Felker 0 siblings, 1 reply; 9+ messages in thread From: Jörg Krause @ 2014-12-08 21:11 UTC (permalink / raw) To: musl 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. > > Rich 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) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: pthread_equal 2014-12-08 21:11 ` pthread_equal Jörg Krause @ 2014-12-09 0:06 ` Rich Felker 2014-12-09 2:18 ` [PATCH] don't shadow functions with macros in C++ Bobby Bingham 0 siblings, 1 reply; 9+ messages in thread From: Rich Felker @ 2014-12-09 0:06 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] don't shadow functions with macros in C++ 2014-12-09 0:06 ` pthread_equal Rich Felker @ 2014-12-09 2:18 ` Bobby Bingham 2014-12-09 22:33 ` Jörg Krause 2014-12-10 3:37 ` Rich Felker 0 siblings, 2 replies; 9+ messages in thread From: Bobby Bingham @ 2014-12-09 2:18 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1947 bytes --] C++ programmers typically expect something like "::function(x,y)" to work and may be surprised to find that "(::function)(x,y)" is actually required due to the headers declaring a macro version of some standard functions. We already omit function-like macros for C++ in most cases where there is a real function available. This commit extends this to the remaining function-like macros which have a real function version. --- include/complex.h | 2 ++ include/pthread.h | 2 ++ include/threads.h | 2 ++ 3 files changed, 6 insertions(+) diff --git a/include/complex.h b/include/complex.h index 13a45c5..e1af0d5 100644 --- a/include/complex.h +++ b/include/complex.h @@ -101,6 +101,7 @@ double creal(double complex); float crealf(float complex); long double creall(long double complex); +#ifndef __cplusplus #define __CIMAG(x, t) \ ((union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1]) @@ -111,6 +112,7 @@ long double creall(long double complex); #define cimag(x) __CIMAG(x, double) #define cimagf(x) __CIMAG(x, float) #define cimagl(x) __CIMAG(x, long double) +#endif #define __CMPLX(x, y, t) \ ((union { _Complex t __z; t __xy[2]; }){.__xy = {(x),(y)}}.__z) diff --git a/include/pthread.h b/include/pthread.h index f7c9568..2697e8b 100644 --- a/include/pthread.h +++ b/include/pthread.h @@ -84,7 +84,9 @@ __attribute__((const)) pthread_t pthread_self(void); int pthread_equal(pthread_t, pthread_t); +#ifndef __cplusplus #define pthread_equal(x,y) ((x)==(y)) +#endif int pthread_setcancelstate(int, int *); int pthread_setcanceltype(int, int *); diff --git a/include/threads.h b/include/threads.h index 0e5836c..0179482 100644 --- a/include/threads.h +++ b/include/threads.h @@ -51,7 +51,9 @@ void thrd_yield(void); thrd_t thrd_current(void); int thrd_equal(thrd_t, thrd_t); +#ifndef __cplusplus #define thrd_equal(A, B) ((A) == (B)) +#endif void call_once(once_flag *, void (*)(void)); -- Bobby Bingham [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] don't shadow functions with macros in C++ 2014-12-09 2:18 ` [PATCH] don't shadow functions with macros in C++ Bobby Bingham @ 2014-12-09 22:33 ` Jörg Krause 2014-12-10 3:37 ` Rich Felker 1 sibling, 0 replies; 9+ messages in thread From: Jörg Krause @ 2014-12-09 22:33 UTC (permalink / raw) To: musl On Mo, 2014-12-08 at 20:18 -0600, Bobby Bingham wrote: > C++ programmers typically expect something like "::function(x,y)" to work > and may be surprised to find that "(::function)(x,y)" is actually required > due to the headers declaring a macro version of some standard functions. > > We already omit function-like macros for C++ in most cases where there is > a real function available. This commit extends this to the remaining > function-like macros which have a real function version. > --- > include/complex.h | 2 ++ > include/pthread.h | 2 ++ > include/threads.h | 2 ++ > 3 files changed, 6 insertions(+) > > diff --git a/include/complex.h b/include/complex.h > index 13a45c5..e1af0d5 100644 > --- a/include/complex.h > +++ b/include/complex.h > @@ -101,6 +101,7 @@ double creal(double complex); > float crealf(float complex); > long double creall(long double complex); > > +#ifndef __cplusplus > #define __CIMAG(x, t) \ > ((union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1]) > > @@ -111,6 +112,7 @@ long double creall(long double complex); > #define cimag(x) __CIMAG(x, double) > #define cimagf(x) __CIMAG(x, float) > #define cimagl(x) __CIMAG(x, long double) > +#endif > > #define __CMPLX(x, y, t) \ > ((union { _Complex t __z; t __xy[2]; }){.__xy = {(x),(y)}}.__z) > diff --git a/include/pthread.h b/include/pthread.h > index f7c9568..2697e8b 100644 > --- a/include/pthread.h > +++ b/include/pthread.h > @@ -84,7 +84,9 @@ __attribute__((const)) > pthread_t pthread_self(void); > > int pthread_equal(pthread_t, pthread_t); > +#ifndef __cplusplus > #define pthread_equal(x,y) ((x)==(y)) > +#endif > > int pthread_setcancelstate(int, int *); > int pthread_setcanceltype(int, int *); > diff --git a/include/threads.h b/include/threads.h > index 0e5836c..0179482 100644 > --- a/include/threads.h > +++ b/include/threads.h > @@ -51,7 +51,9 @@ void thrd_yield(void); > > thrd_t thrd_current(void); > int thrd_equal(thrd_t, thrd_t); > +#ifndef __cplusplus > #define thrd_equal(A, B) ((A) == (B)) > +#endif > > void call_once(once_flag *, void (*)(void)); > > -- > Bobby Bingham Many thanks for the patch! Reviewed-by: Jörg Krause <jkrause@posteo.de> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] don't shadow functions with macros in C++ 2014-12-09 2:18 ` [PATCH] don't shadow functions with macros in C++ Bobby Bingham 2014-12-09 22:33 ` Jörg Krause @ 2014-12-10 3:37 ` Rich Felker 1 sibling, 0 replies; 9+ messages in thread From: Rich Felker @ 2014-12-10 3:37 UTC (permalink / raw) To: musl On Mon, Dec 08, 2014 at 08:18:12PM -0600, Bobby Bingham wrote: > C++ programmers typically expect something like "::function(x,y)" to work > and may be surprised to find that "(::function)(x,y)" is actually required > due to the headers declaring a macro version of some standard functions. > > We already omit function-like macros for C++ in most cases where there is > a real function available. This commit extends this to the remaining > function-like macros which have a real function version. > --- Thanks! Committed. Rich ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-12-10 3:37 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-08 14:42 pthread_equal Jörg Krause 2014-12-08 14:56 ` pthread_equal Rich Felker 2014-12-08 16:18 ` pthread_equal Jörg Krause 2014-12-08 16:25 ` pthread_equal Rich Felker 2014-12-08 21:11 ` pthread_equal Jörg Krause 2014-12-09 0:06 ` pthread_equal Rich Felker 2014-12-09 2:18 ` [PATCH] don't shadow functions with macros in C++ Bobby Bingham 2014-12-09 22:33 ` Jörg Krause 2014-12-10 3:37 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).