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