Quoth Daniel Kahn Gillmor on Dec 27 at 9:27 am:
> On 12/23/2011 10:45 PM, Austin Clements wrote:
> > Quoth Dmitry Kurochkin on Dec 10 at 3:25 am:
> >> + /* For some reason the GMimeSignatureValidity returned
> >> +* here is not a const (inconsistent with that
> >> +
On 12/23/2011 10:45 PM, Austin Clements wrote:
> Quoth Dmitry Kurochkin on Dec 10 at 3:25 am:
>> + /* For some reason the GMimeSignatureValidity returned
>> +* here is not a const (inconsistent with that
>> +* returned by
>> +*
On 12/23/2011 10:45 PM, Austin Clements wrote:
Quoth Dmitry Kurochkin on Dec 10 at 3:25 am:
+ /* For some reason the GMimeSignatureValidity returned
+* here is not a const (inconsistent with that
+* returned by
+*
Quoth Daniel Kahn Gillmor on Dec 27 at 9:27 am:
On 12/23/2011 10:45 PM, Austin Clements wrote:
Quoth Dmitry Kurochkin on Dec 10 at 3:25 am:
+ /* For some reason the GMimeSignatureValidity returned
+* here is not a const (inconsistent with that
+*
Quoth Jameson Graef Rollins on Dec 10 at 1:17 pm:
> On Sat, 10 Dec 2011 03:25:48 +0400, Dmitry Kurochkin gmail.com> wrote:
> > + out->is_encrypted = TRUE;
> > + out->is_signed = TRUE;
> >
> > These are set only if we do decryption/verification. But their
> > names and
Thanks for the thorough review!
Quoth Dmitry Kurochkin on Dec 10 at 3:25 am:
> Hi Austin.
>
> +/* The number of children of this part. */
> +int children;
>
> Consider renaming to children_count or similar to make it clear that it
> is a counter and not the actual children.
Good
Thanks for the thorough review!
Quoth Dmitry Kurochkin on Dec 10 at 3:25 am:
Hi Austin.
+/* The number of children of this part. */
+int children;
Consider renaming to children_count or similar to make it clear that it
is a counter and not the actual children.
Good point.
Quoth Jameson Graef Rollins on Dec 10 at 1:17 pm:
On Sat, 10 Dec 2011 03:25:48 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
+ out-is_encrypted = TRUE;
+ out-is_signed = TRUE;
These are set only if we do decryption/verification. But their
names and
On Fri, 9 Dec 2011 14:54:26 -0500, Austin Clements wrote:
> +/* Handle PGP/MIME parts */
> +if (GMIME_IS_MULTIPART_ENCRYPTED (part) && out->ctx->decrypt) {
> + if (out->children != 2) {
> + /* this violates RFC 3156 section 4, so we won't bother with it. */
> +
On Sat, 10 Dec 2011 03:25:48 +0400, Dmitry Kurochkin wrote:
> +notmuch_bool_t decrypt_success;
>
> Perhaps s/decrypt_success/is_decrypted/ for consistency with
> is_encrypted?
This difference doesn't seem so bad to me, since the is_ variables point
to states of the original message, where
Hi Austin.
+/* The number of children of this part. */
+int children;
Consider renaming to children_count or similar to make it clear that it
is a counter and not the actual children.
+notmuch_bool_t decrypt_success;
Perhaps s/decrypt_success/is_decrypted/ for consistency with
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a MIME
part tree becomes a two-line for loop. Furthermore, the MIME node
structure provides easy access to envelopes for message parts as well
as cryptographic
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a MIME
part tree becomes a two-line for loop. Furthermore, the MIME node
structure provides easy access to envelopes for message parts as well
as cryptographic
Hi Austin.
+/* The number of children of this part. */
+int children;
Consider renaming to children_count or similar to make it clear that it
is a counter and not the actual children.
+notmuch_bool_t decrypt_success;
Perhaps s/decrypt_success/is_decrypted/ for consistency with
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a MIME
part tree becomes a two-line for loop. Furthermore, the MIME node
structure provides easy access to envelopes for message parts as well
as cryptographic
Thanks for the review. A new version is on its way...
Quoth Jani Nikula on Nov 29 at 9:11 pm:
> > +mctx->stream = g_mime_stream_file_new (mctx->file);
>
> AFAICT the GMimeStreamFile object owns the FILE * pointer now, and
> closes it later. Calling fclose() on it in
Thanks for the review. A new version is on its way...
Quoth Jani Nikula on Nov 29 at 9:11 pm:
+mctx-stream = g_mime_stream_file_new (mctx-file);
AFAICT the GMimeStreamFile object owns the FILE * pointer now, and
closes it later. Calling fclose() on it in _mime_node_context_free()
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a MIME
part tree becomes a two-line for loop. Furthermore, the MIME node
structure provides easy access to envelopes for message parts as well
as cryptographic
Hi, generally looks good to me, but please find a few comments below.
BR,
Jani.
On Sun, 27 Nov 2011 21:21:09 -0500, Austin Clements wrote:
> This wraps all of the complex MIME part handling in a single, simple
> function that gets part N from *any* MIME object, so traversing a MIME
> part tree
Hi, generally looks good to me, but please find a few comments below.
BR,
Jani.
On Sun, 27 Nov 2011 21:21:09 -0500, Austin Clements amdra...@mit.edu wrote:
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a MIME
part tree becomes a two-line for loop. Furthermore, the MIME node
structure provides easy access to envelopes for message parts as well
as cryptographic
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a MIME
part tree becomes a two-line for loop. Furthermore, the MIME node
structure provides easy access to envelopes for message parts as well
as cryptographic
22 matches
Mail list logo
