From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Mon, 14 Jan 2013 09:25:36 GMT
Subject: Re: [PATCH 06/14] imap-send.c: remove some unused fields from struct store
Message-ID: <50F3CF10.3000602@alum.mit.edu>
In-Reply-To: <20130114061920.GE3125@elie.Belkin>

On 01/14/2013 07:19 AM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
> 
>> --- a/imap-send.c
>> +++ b/imap-send.c
> [...]
>> @@ -772,13 +767,10 @@ static int get_cmd_result(struct imap_store *ctx, struct imap_cmd *tcmd)
>>  				   !strcmp("NO", arg) || !strcmp("BYE", arg)) {
>>  				if ((resp = parse_response_code(ctx, NULL, cmd)) != RESP_OK)
>>  					return resp;
>> -			} else if (!strcmp("CAPABILITY", arg))
>> +			} else if (!strcmp("CAPABILITY", arg)) {
>>  				parse_capability(imap, cmd);
>> -			else if ((arg1 = next_arg(&cmd))) {
>> -				if (!strcmp("EXISTS", arg1))
>> -					ctx->gen.count = atoi(arg);
>> -				else if (!strcmp("RECENT", arg1))
>> -					ctx->gen.recent = atoi(arg);
>> +			} else if ((arg1 = next_arg(&cmd))) {
>> +				/* unused */
> 
> Neat.  Let me try to understand what was going on here:
> 
> When opening a mailbox with the SELECT command, an IMAP server
> responds with tagged data indicating how many messages exist and how
> many are marked Recent.  But git imap-send never reads mailboxes and
> in particular never uses the SELECT command, so there is no need for
> us to parse or record such responses.
> 
> Out of paranoia we are keeping the parsing for now, but the parsed
> response is unused, hence the comment above.
> 
> If I've understood correctly so far (a big assumption), I still am not
> sure what it would mean if we hit this ((arg1 = next_arg(&cmd))) case.
> Does it mean:
> 
>  A. The server has gone haywire and given a tagged response where
>     one is not allowed, but let's tolerate it because we always have
>     done so?  Or
> 
>  B. This is a perfectly normal response to some of the commands we
>     send, and we have always been deliberately ignoring it because it
>     is not important for what imap-send does?

Honestly, I didn't bother to look into this.  I was just doing some
brainless elimination of obviously unused code.

No doubt a deeper analysis (like yours) could find more code to discard,
but I didn't want to invest that much time and this code has absolutely
no tests, so I stuck to the obvious (and even then you found a mistake
in my changes :-( ).

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/