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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html