On Wed, Jul 04, 2007 at 06:00:14PM +0200, Christian Ebert wrote: > * 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. But this is meaningless. The iconv program exists for one purpose only: to convert data between two different encodings. Mutt is a much more complicated program, and it may be that the iconv library is broken in such a way that when mutt calls its functions, it overwrites other variables in mutt that cause it to return from a function call to an address that has unknown code in it, which just happens to be an endless loop, or who knows what... There are numerous possibilities. It is very possible that the way the iconv program's data structures are arranged, being generally fewer and more simplistic, do not overwrite any return addresses on the stack, or whatever. It doesn't mean there's no bug; it just means the programmer got lucky. Sort of. If you've ever taken a computer science class at a school where there were multiple different kinds of machines, you've probably seen a similar phenomenon. A student writes code for an exercise, compiles and runs it, and it works. Then the professor does the same thing on a different machine, and it doesn't. The program has a bug, but by coincidence, the execution environment where the student ran the program just didn't happen to tweak the bug. End result: student still gets an F (or at least, not an A). [In case it's not obvious, this has happened to me. As it turns out, in this particular case I did still get an A, because I was able to show that the bug was due to a standard C library call returning a different value on the two different architectures. Over time, standards change... see the (Linux) manpage for sprintf() for an example.] > > The problem here isn't Mutt's fault in any way, > > I wasn't accusing Mutt. I know you're not, but you have it stuck in your head that Mutt can do something about a bug in a library, and that's just not possible. [Note: I'm relying on the analysis of others being correct that this is a bug in iconv, I have not attempted to verify this myself. Assuming that's correct, it is not possible in any practical way for mutt to work around.] > > 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. That's why we have mutt-users and mutt-dev. :) > and will just say: oh, Mutt freezes, without telling me > anything, I'll just use that other mailer which doesn't freeze. And if that mailer uses iconv, they'll probably run into the bug with that mailer too. :) > > That's a solution that's much easier -- > > depending on the experience of the user It doesn't depend on the user's experience. Finding out that you have a broken iconv and replacing it is inherently simpler than coding a workaround which is impossible to write, no matter how much experience you have. ;-) -- 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:
pgpwlPTZH1dWc.pgp
Description: PGP signature