>OK, I'll check-pick these across to the branch a little later on then.
>Let me know if that's not the right way to do it.
Thanks, Ralph! I personally use git cherry-pick -x, and I think that's
what makes sense. Does anyone disagree?
>On other news, I've moved from Arch Linux's AUR's `nmh' pack
Hi Ken,
> I'm not really liking the idea of having a code fix that only appears
> on the release branch. I'd rather have the same code in 1.7 and
> master. So I say apply the re-write to 1.7.
OK, I'll check-pick these across to the branch a little later on then.
Let me know if that's not the ri
Hi Ken,
> So, I guess I'm a liar ... turns out MacOS X _does_ define
> __WCHAR_MAX__. Although it seems like WCHAR_MAX is the correct macro
> according to POSIX, so maybe getcwidth.c should still switch?
Yes, I can't recall why I plumped for the __ version now. I've pushed a
fix. Indentifiers
>So, I'm back from vacation and trying to digest this all ... and the first
>thing I ran into is that the new ctype code in test/getcwidth.c uses
>__WCHAR_MAX__ ... which is not defined by MacOS X!
So, I guess I'm a liar ... turns out MacOS X _does_ define __WCHAR_MAX__.
Although it seems like WCH
>> I guess we'd like a minimal-change fix for this on the 1.7
>> branch rather than flip to the re-write?
>
>I'd be fine with the re-write for 1.7, or not. Let's see what Ken
>says.
I'm not really liking the idea of having a code fix that only appears on
the release branch. I'd rather have the s
>Yeah, I think the code was assuming if it's not cntrl, and not space,
>then it must be print and therefore width >= 0. But that's clearly not
>true, even here, where Norm's sunglasses don't have a negative width,
>e.g. U+0378.
So, I'm back from vacation and trying to digest this all ... and the
Hi David,
> > Sunglasses have a width of 1 here, that's why David and I don't see
> > the problem.
>
> I'm surprised that I didn't see the same behavior as Norm, because we
> use the same locale, en_US.utf8. Any idea why?
I'm en_GB.utf8, but I don't see it either. It's the wcwidth(3) answer
for
Hi,
David wrote:
> > inc seems to have a similar, if not identical problem.
>
> It's identical: inc uses the same code to print the scan line.
I was surprised recently when plodding through the source that inc(1)
actually uses the scan() function to do the inc-ing, with the scan as a
side effect
Ralph writes:
> Hi Leonardo,
>
> > At least regarding the `make check' (always on NetBSD/amd64 8.99.1),
> > all 104 tests are passed and 7 tests were not run.
>
> Great, thanks.
Yes, thanks to both of you.
> I guess we'd like a minimal-change fix for this on the 1.7
> branch rather than flip to
Ralph writes:
> Sunglasses have a width of 1 here, that's why David and I don't see the
> problem.
I'm surprised that I didn't see the same behavior as Norm, because
we use the same locale, en_US.utf8. Any idea why?
David
___
Nmh-workers mailing list
Norm writes:
> inc seems to have a similar, if not identical problem.
It's identical: inc uses the same code to print the scan line.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Hello Ralph,
Ralph Corderoy writes:
> [...]
> MACHINES says that's ftp/curl on FreeBSD, if you're interested.
> configure checks for its header file and library IIRC. But I'm happy
> with the tests that were run.
> [...]
...indeed now I can report:
All 110 tests passed
(1 t
Hi Leonardo,
> At least regarding the `make check' (always on NetBSD/amd64 8.99.1),
> all 104 tests are passed and 7 tests were not run.
Great, thanks.
> Regarding the not run ones (all expected):
>
> ./test/oauth/test-inc: skipped: no oauth support
MACHINES says that's ftp
Hello Ralph,
> [...]
> I've re-written the MULTIBYTE_ENABLED cpstripped() on git's master
> branch, not the 1.7 one. Could you give it a go with what failed
> before, and ideally run a `make check' and if all's well a
> `NMH_VALGRIND=1 VALGRIND_ME=1 make check' to give it a work out, it
> takes a
Hi Leonardo,
> Sure! Here what I see with your patch applied:
>
> % scan -format '%(decode{subject})' +. 1
> mbtowc(0x20) = 1
> cntrl:0 space:1 blank:1 print:1
> mbtowc(0x1f576) = 4
> cntrl:0 space:0 blank:0 print:0
> wcwidth(0x1f576) = -1
Yeah, I think the code was assuming if it's n
Ralph Corderoy writes:
> Hi Leonardo,
>
> [...]
Hello Ralph,
> That would do it. Could you apply the attached patch and re-run? I'm
> basically interested in how that locale classes it, e.g. iswprint(3).
>
Sure! Here what I see with your patch applied:
% scan -format '%(decode{subject})' +.
Hi Leonardo,
> (gdb) print wide_char
> $2 = 128374 L'\x1f576'
> (gdb) quit
>
> L'\x1f576' (in wide_char) is probably the `dark sunglasses' (U+1F576)
> unicode character
It is. One of three non-ASCII characters in that subject.
$ uip/scan -file 8759.2.email -format '%(decode{subject})' |
Hi again Norm,
I wrote:
> Could you run this scan command with 1.7-RC1
With Leonardo's reply, there's no need to bother.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu
Hello Ralph,
I was bitten by something similar and so I've rebuilt nmh-1.7-RC1 with
debug symbols, attached some (hopefully) useful debug information (I've
used gdb though because AFAIK ltrace isn't available on NetBSD).
Ralph Corderoy writes:
> [...]
> Could you run this scan command with 1.7-RC1
Hi,
> Assertion failed: (w >= 0), function cpstripped, file
> ../nmh/sbr/fmt_scan.c, line 291.
char_len = mbtowc(&wide_char, str, len);
if (char_len < 0) {
altstr = "?";
char_len = mbtowc(&wide_char, altstr, 1);
}
I wonder if mbtowc()'s internal sh
Hi Norm,
> scan applied to an Email like the attached dumps core. I will send
> more particulars, on request.
Could you run this scan command with 1.7-RC1 to make sure it still has
the assert(3) failure on the problem email.
scan -format '%(decode{subject})' cur
And then repeat that but und
Ken Hornstein writes:
>>Does the following command produce readable output, or a complaint?
>>
>>$ printf %s
>>8J+VtlN1buKAmXMgb3V0LCBzYXZpbmdzIE9O4oCUc2hvcCBtYWpvciBhcHBsaWFuY2UgZGVhbHMgbm93
>> | base64 -d | iconv -f utf-8
>
>For me, that works fine. Since I can reproduce it I'll gladly dig int
David Levine writes:
>Does the following command produce readable output, or a complaint?
>
>$ printf %s
>8J+VtlN1buKAmXMgb3V0LCBzYXZpbmdzIE9O4oCUc2hvcCBtYWpvciBhcHBsaWFuY2UgZGVhbHMgbm93
> | base64 -d | iconv -f utf-8
A readable output -- sort of.
Norman Shapiro
___
>Does the following command produce readable output, or a complaint?
>
>$ printf %s
>8J+VtlN1buKAmXMgb3V0LCBzYXZpbmdzIE9O4oCUc2hvcCBtYWpvciBhcHBsaWFuY2UgZGVhbHMgbm93
> | base64 -d | iconv -f utf-8
For me, that works fine. Since I can reproduce it I'll gladly dig into it,
but not for a week or so
Norm wrote:
> % locale
> LANG=en_US.utf8
So is mine.
Does the following command produce readable output, or a complaint?
$ printf %s
8J+VtlN1buKAmXMgb3V0LCBzYXZpbmdzIE9O4oCUc2hvcCBtYWpvciBhcHBsaWFuY2UgZGVhbHMgbm93
| base64 -d | iconv -f utf-8
David
__
Ralph Corderoy writes:
>Hi Ken,
>
>> Ooof, I get:
>
>Like David, I don't. The Subject is two lots of base64 that I think
>decode to
>
> f0 9f 95 b6 53 75 6e e2 80 99 73 20 6f 75 74 2c |Sun...s out,|
>0010 20 73 61 76 69 6e 67 73 20 4f 4e e2 80 94 73 68 | savings ON...sh|
>00
Hi Ken,
> Ooof, I get:
Like David, I don't. The Subject is two lots of base64 that I think
decode to
f0 9f 95 b6 53 75 6e e2 80 99 73 20 6f 75 74 2c |Sun...s out,|
0010 20 73 61 76 69 6e 67 73 20 4f 4e e2 80 94 73 68 | savings ON...sh|
0020 6f 70 20 6d 61 6a 6f 72 2
David Levine writes:
>Norm wrote:
>
>> scan applied to an Email like the attached dumps core. I will send more
>> particulars, on request.
>
>Doesn't dump core for me, and valgrind doesn't notice anything unusual.
>
>I also tried with your .mh_profile that you posted 16 Nov 2016, with
>no problems
Norm wrote:
> scan applied to an Email like the attached dumps core. I will send more
> particulars, on request.
Doesn't dump core for me, and valgrind doesn't notice anything unusual.
I also tried with your .mh_profile that you posted 16 Nov 2016, with
no problems. If you have updated it since
>scan applied to an Email like the attached dumps core. I will send more
>particulars, on request.
Ooof, I get:
Assertion failed: (w >= 0), function cpstripped, file ../nmh/sbr/fmt_scan.c,
line 291.
Abort (core dumped)
Okay! That will get worked on!
--Ken
30 matches
Mail list logo
