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" <vqgs(_at_)irxz(_dot_)com>, "rysu qyvnd"
<vrpll(_at_)wxnsfu(_dot_)com>, "ywwj
q ococr" <oaez(_at_)kzbxdy(_dot_)com>, "xujfzww uiiwggycz"
<vqokfej(_at_)xqssh(_dot_)com>, "jw
nbrgem kajqnehnjc" <nuvr(_at_)rpal(_dot_)com>, "yolkswpmx ymowfbmco"
<xjsiics@rswds
e.com>, "yztyg tmmxcu" <qwdqb(_at_)vhloznu(_dot_)com>, "pfmt andvdka"
<pazj@sbgvimo
xo.com>, "cktwmtdac pjo" <lsblbf(_at_)lvwg(_dot_)com>, "jdassfrjbo wizfis"
<qsawaun
w(_at_)ldah(_dot_)com>, "nsig phq" <rbpm(_at_)pgnqo(_dot_)com>, "ayejhx
skezkgph" <ylyjskze@zr
xto.com>, "bqbqpiu qzrxpcs" <t
$
$ sed 1,2d `mhpath 2` | sed s/To// | head -c 512
: "tduf akbemhynb" <vqgs(_at_)irxz(_dot_)com>,
"rysu qyvnd" <vrpll(_at_)wxnsfu(_dot_)com>,
"ywwjq ococr" <oaez(_at_)kzbxdy(_dot_)com>,
"xujfzww uiiwggycz" <vqokfej(_at_)xqssh(_dot_)com>,
"jwnbrgem kajqnehnjc" <nuvr(_at_)rpal(_dot_)com>,
"yolkswpmx ymowfbmco" <xjsiics(_at_)rswdse(_dot_)com>,
"yztyg tmmxcu" <qwdqb(_at_)vhloznu(_dot_)com>,
"pfmt andvdka" <pazj(_at_)sbgvimoxo(_dot_)com>,
"cktwmtdac pjo" <lsblbf(_at_)lvwg(_dot_)com>,
"jdassfrjbo wizfis" <qsawaunw(_at_)ldah(_dot_)com>,
"nsig phq" <rbpm(_at_)pgnqo(_dot_)com>,
"ayejhx skezkgph" <ylyjskze(_at_)zrxto(_dot_)com>,
"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.
https://plus.google.com/+RalphCorderoy
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers