[Top][All Lists]

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

Re: [Nmh-workers] Weird behavior with non-ascii code in headers

From: Ken Hornstein
Subject: Re: [Nmh-workers] Weird behavior with non-ascii code in headers
Date: Wed, 26 Jun 2013 14:06:16 -0400

>> It might be interesting to understand the failure there.

Well, I was thinking more of the _internals_ ... I understood about the
problem as you described it.

I did some debugging.  Turns out the problem is with cpstripped() in the
format engine.  It calls mbtowc() on every character it processes and
if mbtowc() returns a -1 (which it does in this case), then cpstripped()
stops processing the string.  Turns out fmttest was useful here!

>> Sigh.  It's a tough problem.  Let me ask you: what do you want to happen?
>fprintf(stderr,"non-convertible char found near 
>would be an improvement...

I understand and agree with you that the current behavior is not optimal.
So I'm wondering what others think here.  Specifically:

- I'm not crazy about calling printf()/fprintf() from deep inside a library
  function.  That seems like bad programming to me.  Yes, we do that tons
  of places now, but not in the format library.

- In a more practical sense ... would you even notice a warning message
  that was printed on standard error?  In this scenario the screen would
  likely be cleared by your editor right after the message was printed;
  unless you were really paying attention you woudln't notice it.

- It's not clear to me what the "right" behavior should be.  Should we put
  warning text in the format buffer?  Provide some substitution callback
  routine that higher-level programs could provide?  I'm not really sure
  _what_ is the right behavior.  This gets us into the sticky realm of
  deciding how to handle misformed messages; obviously we have to deal
  with them, but it's not clear to me the right thing to do.

- Just out of curiousity ... what was the mailer that the original sender
  used?  Whatever the original message author used doesn't excuse us
  from doing a better job, of course.


reply via email to

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