On 2014/12/09 00:10, Ben Boeckel <[email protected]> wrote:
> On Mon, Dec 08, 2014 at 22:14:16 +0100, Jörg Krause wrote:
> > FYI: This is the statement of a musl maintainer about this issue:
> > http://www.openwall.com/lists/musl/2014/12/08/15
>
> That is???unfortunate. Macros are basically evil and with this kind of
> attitude, anytime I use a standard C library, POSIX, etc. function from
> C++, I have to first #undef it to make sure I get the right one to be
> "portable" :/ . IMO, if that's the level of burden to be portable to
> your C library, you can keep your patches (nb. I'm not an mpd dev, so
> this opinion isn't binding here). Not to mention that macros have
> approximately zero support for usage inside of C++'s std algorithms (or
> C's limited selection for that matter).
I agree. And I believe Rich's opinion on this is wrong. Not
formally/technically wrong, just wrong as in "I disagree that a
standard library developer should decide that way". Even if something
is formally legal according to some specification, some common sense
must be applied.
Macros should be avoided whenever possible, and inline functions are
almost always the better replacement.
Just look at this MUSL code that broke the MPD build:
int pthread_equal(pthread_t, pthread_t);
#define pthread_equal(x,y) ((x)==(y))
That macro is supposed to optimize some pthread_equal() calls. This
is how it should be done:
static inline int pthread_equal(pthread_t a, pthread_t b) {
return a == b;
}
This is C code, while the former is NOT C code - it escapes from the
"raw" C language into the preprocessor language. My version is
type-safe. And safe with C++. It is longer, but more readable, and
comes without the paranthese hacks necessary in macros. (And there
are many more advantages.) Both generate the same machine code.
It beats me why MUSL developers thought a macro is better; that is so
obviously wrong that I don't know what to say. Inexperienced C
developers often prefer macros over inline functions, as did I decades
ago when I was new to C.
I agree with Ben, and my motivation to keep MPD compatible with a
badly designed standard library is not big.
And no, MPD will not add workarounds for MUSL (#undef). Removing "::"
was barely acceptable, even though I don't like that change.
Max
_______________________________________________
mpd-devel mailing list
[email protected]
http://mailman.blarg.de/listinfo/mpd-devel
