For 1.6: make mutt more robust for number parsing

[Rocco Rutte <pdmef@xxxxxxx>]

Hi,

when "parsing" numbers with atoi() and non-numeric input, the results 
are usually unexpected. Currently, mutt uses atoi() in a number of 
places. I've hacked up a patch adding mutt_atoi() (same for short and 
long) as wrappers around strtol() to do the conversion (or test for it) 
and report errors so consumers can act accordingly. The current patch is 
at (or the pdmef/atoi branch of my tree):

  
<http://user.cs.tu-berlin.de/~pdmef/mutt/patches/patch-1.5.14hg.pdmef.atoi.3.diff>

Some problematic cases with current mutt which all get accepted:

  config: score ~A +foo
  config: set folder=pop://foo@host:bar/
  command line: mutt -d foobar
  index: jump to message 3foobar
  ...

and likely many more (for example date parsing: there was a check for 
the first char of a day of month being numeric so that '3foobar' would 
heapily get parsed as being valid I suppose, the year wasn't checked at 
all; read: likely one could have fun with date parsing).

When doing the patch, I wasn't aware of cases were this leads to really 
undesired behaviour like crashing mutt or security problems so it isn't 
that serious after all and thus doesn't need urgent fixing.

Also I'm not sure whether we should be even more paranoid and use the 
wrappers for parsing server responses. I'm not sure what the POP, IMAP 
and SMTP parts do if they use atoi() results from non-numeric input and 
whether this could lead to security issues with malicious servers.

Note that I'm not entirely sure whether this strict input checking isn't 
overkill but I tend to answer that question with "no".

Comments?

  bye, Rocco
--
:wq!