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