On Fri 2016-12-02 09:19:29 -0500, Jeffrey Stedfast wrote:
I've commited this patch with a slight modification...
thanks! a bit more commentary interleaved below:
diff --git a/gmime/gmime-gpg-context.c b/gmime/gmime-gpg-context.c index 0a05ed2..2ca280a 100644 --- a/gmime/gmime-gpg-context.c +++ b/gmime/gmime-gpg-context.c @@ -763,7 +763,7 @@ gpg_ctx_op_start (struct _GpgCtx *gpg) } /* run gpg */ - execvp (gpg->ctx->path, argv); + execvp (gpg->ctx->path ? gpg->ctx->path : "gpg", argv);If g_mime_gpg_context_new () always sets path, then we don't need to do this messy hack.
In other software projects, i've found it's useful to distinguish
between the "default" case and the case where something has been
explicitly set by the programmer. For example, the config settings in
firefox's about:config for boolean values actually end up being a
tri-state: Default, User-set:True, and User-set:False. This distinction
allows an update to firefox to change the defaults while not disturbing
people who've explicitly stated a commitment to one setting, even if it
happens to be the current default.
I admit that i don't have a specific case where that's useful in gmime
here (certainly we're not talking about the firefox code upgrade path
for an object that lives in memory), but preserving ctx->path == NULL
for the "default" case would provide a way for any code that wants to
find out whether this is "default" or not to know.
at any rate, i'm happy with either approach, just wanted to explain why
i don't think the above is actually a "messy hack" any more than the
other approach :)
Regards,
--dkg
Attachment:
signature.asc
Description: PGP signature