bug#4358: 23.1.50; Arithmetic overflow errors break imap

[James Cloos <cloos@jhcloos.com>]

>>>>> "Stefan" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

Stefan> Try setting debug-on-error to t, and if that doesn't cut it, try
Stefan> setting debug-on-signal to t.

I thought I had tried that, but apparently not.  (Perhaps I fell asleep
planning to do it and woke thinking I had???)

The backtrace I get from trying to exit the *Summary* buffer for my
INBOX folder looks like:

Debugger entered--Lisp error: (overflow-error "4294967287")
  read(#<buffer  *nnimap* lugabout>)
  imap-parse-status()
  imap-parse-response()
  imap-arrival-filter(#<process imap> "* STATUS \"INBOX\" (UNSEEN 4294967287)
\n1577 OK STATUS completed
\n")
  accept-process-output(#<process imap> 0 100)
  imap-wait-for-tag(1577 nil)
  imap-send-command-wait(("STATUS \"" "INBOX" "\" " "(UNSEEN)"))
  imap-mailbox-status("INBOX" unseen " *nnimap* lugabout")
  nnimap-update-unseen("INBOX" "lugabout")
  nnimap-close-group("INBOX" "lugabout")
  gnus-close-group("nnimap+lugabout:INBOX")
  gnus-summary-exit()
  call-interactively(gnus-summary-exit nil nil)

which (of course) shows that the imapd is sending the large value.

Which quite simply does not make sense, as there are certainly not
that many unseen messages in INBOX.  A quick check via telnet shows
that the imapd does indeed reply to a STATUS INBOX (UNSEEN) command
with that string, so I'll have to debug that.

But it would still be nice if gnus didn't crap out when that occurs.

What can be done to deal with that w/o raising an exception?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6