On 27 September 2011 12:27, Daniel Fischer <[email protected]> wrote: > So the only opportunity for iconv to have a part in this would be during > git cloning, wouldn't it? Does git use iconv when cloning?
Sorry I should have said libiconv. GHC's base library links against libiconv to implement encoding/decoding for encodings that are not built in. The "UTF-8" encoding is built in, but "UTF8" is not built in so I fixed the test when I corrected my spelling error. But the fact that it failed with "UTF8", when it was using libiconv, shows that there is some issue with how your libiconv works. I've looked at the source of your iconv and figured out what is going on. Basically, it has a performance hack for when the source and destination encodings are the same where it essentially just does a memcpy. Unfortunately, this means that if the sequence to be converted contains an invalid byte sequence, you don't get an error. GHC currently relies on this error occurring so it can fix things up. TL;DR although the immediate problem is solved (test passes) this has uncovered a real bug elsewhere :-( Thanks for the information, Max _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
