On 2014/03/15 18:51, Pete Beardmore <[email protected]> wrote:
> [multiple sighs]. verified, you're absolutely right yes, however,
> the same issue would occur if a sink set in the config was removed,
> hence it's an existing issue

That's not a valid argument.  If the user tells MPD to use a specific
sink and then removes that sink, then MPD can't possibly fulfill the
user's wish.  That's a user error, and we don't need a programmatic
solution for that.

But if the user tells MPD to use a specific sink, and the next day
finds that MPD wants to connect to a very different sink that doesn't
exist anymore, different from the one he configured in mpd, he will be
disappointed and wondering what the hell MPD is doing.

This whole idea leaves me with a bad taste.

> -casting away the const flag on the po->sink pointer to allow
> runtime setting to nullptr.

I believe you misunderstand the "const" here:

- const char *sink;
+ char* sink;

The "const" refers to the string data, not to the string pointer.

Note the difference between:

 const char *foo;
 char *const foo;
 const char *const foo;

I still don't like the new version of the patch (even without this
"const" chaos), because it makes MPD lose information, and still leads
to a surprising situation.  Not less surprising than before, not even
better, just a little bit different.  The change is not an
improvement.
_______________________________________________
mpd-devel mailing list
[email protected]
http://mailman.blarg.de/listinfo/mpd-devel

Reply via email to