imapparse.c / getnum

[Bron Gondwana]

On Thu, Jun 17, 2010 at 03:44:40PM -0500, Patrick Goetz wrote:
> On 06/16/2010 10:09 PM, Bron Gondwana wrote:
> >I'm also replacing everywhere that we advance a character
> >pointer through a string and do the same algorithm with
> >parsenum in lib/util.c.  It will have the same logic.  No
> >more MAXLITERAL.
> 
> The getnum code looks basically the same as the bit that used
> MAXLITERAL (with MAXLITERAL =~ INT_MAX/10 - 10).
> Of course now the question is "why the minus 10?).

Seriously?  Ok, minus 9 maybe...

I'll just paste the algorithm again:

    while (cyrus_isdigit(*p)) {
        if (result > (INT_MAX/10 - 10))
            fatal("num too big", EC_IOERR);
        result = result * 10 + *p++ - '0';
    }

(this is the one to parse a character string rather than the one
 that pulls characters from a protstream)

Notice the calculation line.  We're just about to multiply result
by 10 and then add a digit.  So we need to make sure there's
space for it.  In theory we might wind up with a value up to 10
less than INT_MAX, but that's still pretty close.
 
> The patch you sent previously appears to be incompatible with the
> 2.3.16 tree; for example, the 2.3.16 ~/lib/libconfig.h doesn't have
> the line
>  extern int config_auditlog;

Yeah - true.  I just applied it on top of my future branch code.
I can backport it easily enough - but honestly there's no real
need.  It's an annoying bloody refactor, but a worthwhile one,
which is why I've dumped nearly a day's work on it!

> I didn't check beyond this, but we'll just go ahead and patch
> imapparse.c with the existing /20 --> /10 patch and wait for the
> next release to fix up the patch set.

Good plan.  /10 is probably enough.  I wouldn't go bigger than that
or it could wrap.
 
> I gave myself a headache trying to figure out how config_getenum()
> works and am probably going to work on something else for the rest
> of the day.  (Who says that perl is harder to maintain than C?  <:))

Me.  There's only a certainly level of evil you can manage in C.
The potential for evil in perl is much greater.  That said, Perl
is much easier to write :)  I enjoy Perl.  Will enjoy getting back
to playing around with it again once I put Cyrus 2.4 to bed.

> Thanks for working on this stuff and responding to my questions!

No worries.  I'm working on Cyrus code all the time at the moment
anyway, so a little side branch doesn't hurt too much :)  Anything
that tidies up the code is good.

Bron.