<<< Date Index >>>     <<< Thread Index >>>

Re: mutt freezes when fed high character in header



* Derek Martin on Wednesday, July 04, 2007 at 10:21:08 -0400:
> On Wed, Jul 04, 2007 at 03:46:37PM +0200, Christian Ebert wrote:
>> I understand, and -- layman's speak here -- the change in iconv
>> might've been in the /library/ not the program, but perhaps there
>> is some way to catch what the library says from Mutt like old
>> iconv, the program, does.
> 
> There isn't.  The library becomes part of the program by dynamically
> linking the code from the library into Mutt's executable program, but
> mutt has no control over what it does...  If the library decides to go
> into an endless loop,

But iconv, the program, uses the same broken library and doesn't
go into a loop, or detects the loop in the lib, and error-exits
immediately.

> mutt has no way to determine that, and no way to
> do anything about it, because it isn't Mutt's code that's running at
> that point -- it's the library's code that is executing.  As I said,
> what you're asking is impossible.

Because iconv, the program, has access to some return codes from
the broken lib that Mutt does not have access to?

> An alternative would be to re-code Mutt to run iconv as an external
> program, and write some very silly and complex code to see if it's
> taking too long to do what it's supposed to do, but this doesn't
> really solve the fundamental program: iconv is broken.  You need a new
> one.

I completely agree that is the best way.

> The problem here isn't Mutt's fault in any way,

I wasn't accusing Mutt.

> and the solution is to update your libiconv to one that's not
> broken.

Unfortunately there's nothing that tells an unexperienced user
that it is iconv's fault. See the message that started this
thread. amavis told him about an undeclared header. And some
people don't run amavis, or are not as obsessed as I am about
Mutt, and will just say: oh, Mutt freezes, without telling me
anything, I'll just use that other mailer which doesn't freeze.

> That's a solution that's much easier --

depending on the experience of the user

> and much smarter -- than trying to write a framework to monitor
> system libraries to make sure they behave reasonably.

Of course I /want/ to be smart ;-)

c
-- 
Nichts gibt so sehr das Gefühl der Unendlichkeit als wie die Dummheit
                                                  -- Ödön von Horváth