On Tue, May 19, 2015 at 08:43:56 +0200, Max Kellermann wrote:
> On 2015/05/19 02:07, Yclept Nemo <orbisvi...@gmail.com> wrote:
> > So a password_backend ("command") that runs a command and retrieves stdout
> > and return code? Any recommendations boost, popen, etc?
>
> That was one thing I didn't agree with. I wouldn't do that.
Hmm. Any reason why? I would think pass would be fairly popular with
folks using mpd (but maybe I'm just skewing things). Also, I don't
personally use pass, so maybe waiting until someone who does to come by
and make a patch would be better in any case.
> > This (mpd.secret.py) is not a hard runtime dependency; it is a script to
> > help end-users setup libsecret keyrings.
>
> So this is not MPD specific? Is there no other existing tool to do
> that? If not, why don't you submit your tool to the libsecret
> project? I don't think this belongs here.
It's MPD-specific in that it uses the schema MPD expects, but it's a
run-once tool. It probably doesn't belong in /usr/bin though; probably
/usr/libexec/mpd or even under /usr/share/doc/examples or something.
> > > The caller should probably own the data returned here (other backends
> > > use strdup for valid values, and NULL be used on error paths).
>
> If the value is a "const" pointer, the caller doesn't own it, because
> you can't "free" a const pointer.
>
> But it's right, the semantics of ownership must be well-defined.
My thought was to just make *all* password functions return new memory
for the caller to manage rather than trying to make special cases.
> Because these functions return pointers into a larger object (the
> global configuration). They are just looking up existing objects.
If they all strdup(), the caller has obvious semantics, no? The extra
memory won't float around too long I would expect (and there are usually
pitfalls where "this is owned by someone else" pointers are used
anyways).
--Ben
_______________________________________________
mpd-devel mailing list
mpd-devel@musicpd.org
http://mailman.blarg.de/listinfo/mpd-devel
