On Tue, Dec 09, 2014 at 07:21:47 +0100, Max Kellermann wrote:
> 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.
Well, it seems that Rich is rules lawyering[1] saying "but it's
allowed!"…which is something I thought people didn't like about glibc
(see the reverse direction memcpy with flash bug). The inline function
is strictly better here, so I have no idea why the macro was even
considered.
> 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.
Well, it looks like they might fix this for C++ at least:
http://www.openwall.com/lists/musl/2014/12/09/2
> I agree with Ben, and my motivation to keep MPD compatible with a
> badly designed standard library is not big.
And here I thought musl was supposed to be better than other libc
projects (to the point of rejecting processor-feature optimized routine
replacements for 'simplicity'[2] then going and doing insanity like this).
> And no, MPD will not add workarounds for MUSL (#undef). Removing "::"
> was barely acceptable, even though I don't like that change.
With the new patch, MPD can now error out on "#ifdef pthread_equal" if
you want to push back on such behavior.
--Ben
[1]http://www.openwall.com/lists/musl/2014/12/09/1
[2]Though maybe I'm misremembering this detail; can't seem to find a
source.
_______________________________________________
mpd-devel mailing list
mpd-devel@musicpd.org
http://mailman.blarg.de/listinfo/mpd-devel
