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

Re: mutt freezes when fed high character in header



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, 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.

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.

The problem here isn't Mutt's fault in any way, and the solution is to
update your libiconv to one that's not broken.  That's a solution
that's much easier -- and much smarter -- than trying to write a
framework to monitor system libraries to make sure they behave
reasonably.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

Attachment: pgpRH11pfB4oV.pgp
Description: PGP signature