Created attachment 43735 [details] [review]
camel patch

I'd like to see a backtrace of the crash. the patch doesn't seem to
have anything to do with a crash fix.

also, is_lwsp() is the macro that should be used, don't create a new one.

Will supply the crash log within a couple of hrs, I'm rebuilding evo now

FWIW I couldn't recreate the crash.

so it sounds like a bug in one of the libraries, e.g. iconv.

looking at the function though, maybe its wrong.  it isn't what goes
into the rfc2047 encoded output though, so it isn't generating tokens
with those characters as separators, so it wont break the encoding (i
think).

still, i'd like to see the bt before any patch goes in thanks

(gdb) where

+ Trace 46856

I think now you can see why fixing the above function prevents the
crash, camel_header_encode_string argument in uTF-8 is

0xe38080 0xe38080 0x61

the first 2 are unicode space equivalents they pass the
g_unichar_isspace test, what happens here is the second e38080 cuases
the encoding to be 2, then 0x61, or 'a' passed to camel_charset_best,
which returns NULL for it is US-ASCII, the same when passed to
rfc2047_encode_word causes a crash.

The way to avoid this is obey the rfc's and treat 0xe38080 as non
spaces, then things work OK.

Jeff, you aked me to use the is_lwsp, was it the referece to
camel_mime_is_lwsp or plain is_lwsp ?

plain old is_lwsp(). it's a private macro that uses a
camel_mime_specials[] table.

camel_mime_is_lwsp makes more sense for me than the is_lwsp defined in
camel-url-scanner.c (which deals with urls) or the one defined in
camel-imap4-specials.h (which's downstream imap4 specific)

BTW, I hope you agreed to this being a bug.

er, oops. I forgot that the is_lwsp() macro was namespaced to
camel_mime_is_lwsp(). So yes, use camel_mime_is_lwsp().

and yes, it is a bug.

Created attachment 43738 [details] [review]
camel patch

OK to commit ?

ok, commitetd to CVS. thanks for the patch.