unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Austin Clements <amdragon@MIT.EDU>
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH v2 5/5] cli: lazily create the crypto gpg context only when needed
Date: Fri, 18 May 2012 12:45:08 -0700	[thread overview]
Message-ID: <87txzd9su3.fsf@servo.finestructure.net> (raw)
In-Reply-To: <20120518192157.GV11804@mit.edu>

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

On Fri, May 18 2012, Austin Clements <amdragon@MIT.EDU> wrote:
>> +    /* Lazily create the gpgctx if it's needed and hasn't been initialized yet */
>> +    if ((GMIME_IS_MULTIPART_ENCRYPTED (part) || GMIME_IS_MULTIPART_SIGNED (part))
>> +	&& (node->ctx->crypto->verify || node->ctx->crypto->decrypt)) {
>> +	if (!node->ctx->crypto->gpgctx) {
>
> These if conditions could be combined, like
>
>     if ((GMIME_IS_MULTIPART_ENCRYPTED (part) || GMIME_IS_MULTIPART_SIGNED (part))
> 	&& (node->ctx->crypto->verify || node->ctx->crypto->decrypt)
> 	&& !node->ctx->crypto->gpgctx) {
>
> When I see two nested 'if's like this, I expect there to be an else
> part to the inner if or something after the inner if (why else would
> it be separate?) and then I wind up matching braces when I don't see
> anything.  Also, one 'if' would save a level of indentation.

To explain what I was explaining on IRC, and what I should have noted in
the original patch, I did this on purpose because I'm looking forward to
the S/MIME support I was trying to get working.

gmime 2.6 provides a separate context for pkcs7 (S/MIME).  In this
context initialization section we will therefore have to test for
initialization of the relevant context.  Since I knew that going into
this I decided to anticipate it by constructing things this way now
future diffs wouldn't have to include the indentation of this section
and could therefore be cleaner and smaller.  If folks have issue with
that explanation let me know.

> Perhaps "If crypto->gpgctx is NULL, it will be lazily initialized."?
> The variable does have to be "initialized", in the sense that it can't
> be uninitialized data.

That sounds like a better wording.  I'll fix.

> It's slightly awkward that it's the caller's responsibility to free
> this lazily constructed object.  That should probably be documented.
> We could more carefully reference count it, but I think that would
> actually be worse because the reference count would probably bounce
> through zero frequently.

I agree that this is awkward.  Is there a suggestion on how to do it
better?  We only want to initialize it if it's needed, and only
_mime_node_create knows that.  And we don't want to free it with
_mime_node_context_free, or something, only to have to reinitialize it
again with the next node or message.  Thoughts?

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

  reply	other threads:[~2012-05-18 19:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 17:32 [PATCH v2 0/5] cli: improve handling of crypto parameters and contexts Jameson Graef Rollins
2012-05-18 17:32 ` [PATCH v2 1/5] cli: new crypto structure to store crypto contexts and parameters Jameson Graef Rollins
2012-05-18 17:32   ` [PATCH v2 2/5] cli: modify mime_node_open to take crypto struct as argument Jameson Graef Rollins
2012-05-18 17:32     ` [PATCH v2 3/5] cli: modify mime_node_context to use the new notmuch_crypto_t Jameson Graef Rollins
2012-05-18 17:32       ` [PATCH v2 4/5] cli: new crypto verify flag to handle verification Jameson Graef Rollins
2012-05-18 17:32         ` [PATCH v2 5/5] cli: lazily create the crypto gpg context only when needed Jameson Graef Rollins
2012-05-18 19:21           ` Austin Clements
2012-05-18 19:45             ` Jameson Graef Rollins [this message]
2012-05-18 20:37               ` Daniel Kahn Gillmor
2012-05-18 20:42                 ` Jameson Graef Rollins
2012-05-19 11:26         ` [PATCH v2 4/5] cli: new crypto verify flag to handle verification Jani Nikula
2012-05-19 16:28           ` Jameson Graef Rollins
2012-05-18 19:09       ` [PATCH v2 3/5] cli: modify mime_node_context to use the new notmuch_crypto_t Austin Clements
2012-05-18 19:17         ` Jameson Graef Rollins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87txzd9su3.fsf@servo.finestructure.net \
    --to=jrollins@finestructure.net \
    --cc=amdragon@MIT.EDU \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).