On 2014/12/09 17:06, Ben Boeckel <maths...@gmail.com> wrote:
> 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).

It is allowed, and following the rules word by word is a good thing,
but that's not all there is to good software design.

I like how glibc changed memcpy().  There is an advantage here - it is
faster on some CPUs.  Maybe somebody made a mistake and didn't know
the difference between memcpy() and memmove() - but we got over it.
Those people fixed their bugs, memcpy() has become faster, happy end.

But there is no advantage in MUSL's macros (compared to inlines).  And
that's the big difference.

> Well, it looks like they might fix this for C++ at least:
> 
>     http://www.openwall.com/lists/musl/2014/12/09/2

Facepalm!!

This is the wrong way to approach this problem!  Switching off the
macros completely instead of converting them to inline functions means
there is a disadvantage for C++ developers.  (Assuming that there ever
was an advantage of adding these macros in the first place.)

> With the new patch, MPD can now error out on "#ifdef pthread_equal" if
> you want to push back on such behavior.

No, because the pthread_equal macro definition could look like this:

 #define pthread_equal pthread_equal

Quite a few libraries follow this practice.  It does not break C++,
but you can detect if a function is available.  Not that I like this
kind of design.

Max
_______________________________________________
mpd-devel mailing list
mpd-devel@musicpd.org
http://mailman.blarg.de/listinfo/mpd-devel

Reply via email to