[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] [pick -to] apparently failing for long 'To:' header

From: Ralph Corderoy
Subject: Re: [Nmh-workers] [pick -to] apparently failing for long 'To:' header
Date: Sat, 06 May 2017 17:14:25 +0100

Hi David,

> Tom wrote:
> > $ pick -to mytkhcsh
> > pick: no messages match specification
> That's due to this hard-coded limit in picksbr.c:
>     #define LBSIZE  1024
>     #define ESIZE   1024

scan(1) has similar, but different.

     * Buffer size for content part of header fields.  We want this
     * to be large enough so that we don't do a lot of extra FLDPLUS
     * calls on m_getfld but small enough so that we don't snarf
     * the entire message body when we're only going to display 30
     * characters of it.
    #define SBUFSIZ 512

So one can't use it to show the Tom's To's value.

    $ uip/scan -width 0 -format '%{to}' +. 2 | fold -72
    "tduf akbemhynb" <address@hidden>, "rysu qyvnd" <address@hidden>, "ywwj
    q ococr" <address@hidden>, "xujfzww uiiwggycz" <address@hidden>, "jw
    nbrgem kajqnehnjc" <address@hidden>, "yolkswpmx ymowfbmco" <address@hidden
    e.com>, "yztyg tmmxcu" <address@hidden>, "pfmt andvdka" <address@hidden
    xo.com>, "cktwmtdac pjo" <address@hidden>, "jdassfrjbo wizfis" <qsawaun
    address@hidden>, "nsig phq" <address@hidden>, "ayejhx skezkgph" 
    xto.com>, "bqbqpiu qzrxpcs" <t
    $ sed 1,2d `mhpath 2` | sed s/To// | head -c 512
    : "tduf akbemhynb" <address@hidden>,
        "rysu qyvnd" <address@hidden>,
        "ywwjq ococr" <address@hidden>,
        "xujfzww uiiwggycz" <address@hidden>,
        "jwnbrgem kajqnehnjc" <address@hidden>,
        "yolkswpmx ymowfbmco" <address@hidden>,
        "yztyg tmmxcu" <address@hidden>,
        "pfmt andvdka" <address@hidden>,
        "cktwmtdac pjo" <address@hidden>,
        "jdassfrjbo wizfis" <address@hidden>,
        "nsig phq" <address@hidden>,
        "ayejhx skezkgph" <address@hidden>,
        "bqbqpiu qzrxpcs" <t$

> We should replace that with dynamic allocation, so that vm becomes the
> limiting factor.  Anyone?

I think a limit so large that a breach suggests something's gone wrong,
or it's a corrupt email, e.g. 100 KiB.  But that obviously shouldn't be
allocated each time;  it should grow to that as needed.  This will all
be m_getfld() I assume?  Ken's nememsis?

> In the meantime, we could increase those constants.  I don't think
> that they determine the size of any stack variables, just static and
> heap, so we could increase them a lot.

You introduced, IIRC, NMH_BUFSIZ as min(8192, BUFSIZ).  That would seem
sufficient for one logical header over multiple physical lines for the
moment?  It could be used as the value of LBSIZE, etc., to minimise diff
noise as it's just a temporary fix?  I don't mind having a poke about
for the limits that need upping if that's agreeable.

Cheers, Ralph.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]