>> 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 >%s",*(max(source_string,bad_char-5)) >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. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
