[Top][All Lists]

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

Re: [Nmh-workers] scan -width behaves oddly in 1.5RC3

From: Ken Hornstein
Subject: Re: [Nmh-workers] scan -width behaves oddly in 1.5RC3
Date: Wed, 06 Jun 2012 13:16:17 -0400

>(I forget the provenance of this thing, but it's likely a modified
>version of what exmh supplies.)

AFAICT exmh doesn't supply that, but I guess it doesn't matter.

>In addition to the -form argument, exmh
>sticks in a -width argument.  That's always behaved as expected with nmh
>1.0.4, but something weird is happening with the final putnum call in
>1.5RC3: sometimes, when the line is almost full, I see "()" at the end,
>where I would expect to see "(" and a digit or two, the rest being
>suppressed by the width limit.  Here is an example:

So, this doesn't happen to me.  Specifically, on MacOS X:

% scan -format '%5(msg)%<(cur)+%| %>%<{replied}-%|%<{encrypted}E%| 
%02(hour{date}):%02(min{date})%<{date} %|*%> 
%(decode{subject}) (%(putnum(size)))' -width 140 691
  691  06/06 12:27  CANADA LOTTERY             Please view the attachment and 
contact Mr.Johann Espry for your claim and payment. (45863)
% scan -format '%5(msg)%<(cur)+%| %>%<{replied}-%|%<{encrypted}E%| 
%02(hour{date}):%02(min{date})%<{date} %|*%> 
%(decode{subject}) (%(putnum(size)))' -width 135 691
  691  06/06 12:27  CANADA LOTTERY             Please view the attachment and 
contact Mr.Johann Espry for your claim and payment. (458

Which is what you'd expect.  Also, the right thing happens for me on SLES
system here, so it's not a MacOS X issue (I tested the MacOS X system using
1.5-RC3 and the SLES system against nmh-1.3, but it's the same code).

So, why doesn't it work for you?  Well, back in 1.0.4 the FT_NUM
instruction was implemented with a PUTD() macro, which was a
hand-rolled replacement for snprintf().  But that couldn't handle
10 digit values, so in 2003 the calls to PUTD were simply replaced
with snprintf().  So my conjecture is that on your systmes if
snprintf() cannot fit a value in the width specified then it simply
refuses to put anything in there.  My reading of the specification
is that this is the correct behavior.  Again, this is just a guess.
I see a note in the Linux man page that says in glibc < 2.0.6 if
there is truncation by snprintf() it will return -1 instead of the
width that was supposed to be written.  Looking at the code ... I
think that's what's happening.  If snprintf() returns -1, the format
code won't move the character pointer because it's interpreting
that as an error.

If you want to debug this, look at sbr/fmt_scan.c:fmt_scan(), and search
for FT_NUM.  If you want to make a bit more sense of what you see in
fmt_scan and how it maps to a format string you can use fmtdump to dump
out the instructions for a particular format string.  Looking at that
string ... there's only one FT_NUM instruction in there, so setting a
breakpoint on that line should be pretty easy.


reply via email to

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