[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Weird behavior with non-ascii code in headers
From: |
David Levine |
Subject: |
Re: [Nmh-workers] Weird behavior with non-ascii code in headers |
Date: |
Wed, 26 Jun 2013 22:42:52 -0400 |
Ken wrote:
> The problem here really more of a bug in the I18N handling _at the
> output stage_, and is really kinda obscure; the issue in my mind is:
> how do we deal with that? This also comes up with other headers,
> like Subject; I expect the same thing would happen there. Part of
> me thinks that if we run into a non-ASCII character in a header in
> the format engine we should simply replace it with a "?".
I agree with Ralph: ripple the error back up (with returns,
not longjmps :-) and don't even open the editor. In this
case, it looks like that might not be too difficult:
fmt_scan() currently doesn't return anything useful. Fix
that, and have its callers check the return value.
The return could value get a bit messy if we don't want
cpstripped() or fmt_scan() to print the error message, but
just a bit.
And isn't that necessary to protect against potentially
dangerous behavior: what if Valdis had an alias that
matched the degenerate address that ended up in his draft?
David
- Re: [Nmh-workers] Weird behavior with non-ascii code in headers, (continued)
- Re: [Nmh-workers] Weird behavior with non-ascii code in headers,
David Levine <=
- Re: [Nmh-workers] Weird behavior with non-ascii code in headers, David Levine, 2013/06/26
- Re: [Nmh-workers] Weird behavior with non-ascii code in headers, David Levine, 2013/06/26
- Re: [Nmh-workers] Weird behavior with non-ascii code in headers, David Levine, 2013/06/27
- Re: [Nmh-workers] Weird behavior with non-ascii code in headers, David Levine, 2013/06/27