On Mon, 2007-12-24 at 13:21 +0800, jacky wrote: > Yes, I use a fixed length string to store some value, it maybe > overflow. I write another version by using heap insteads of > stack. I think the stack version is simple and enough, so I > send it only. Two version of rfc2047_decode_word() is in > attachment. Can you explain the incorrect logic in my patch?
Just doing decword = malloc (SIZE) in stead of decword[SIZE] (heap vs. stack) just moves the location where you overflow (stack or heap), it doesn't change the fact that you overflow. This one still overflows if strlen(prev_charset) > 1024 ret = conv_to_utf8 (prev_charset, decword, inlen, utf8_decword_ptr, outlen); This one still overflows if (inptr-start) > 1024 quoted_decode(start, inptr-start, decword_ptr); I don't know if there are encodings with more than two bytes per character, but if so this one overflows too (1024 vs. 2048). ret = conv_to_utf8 (curr_charset, decword, inlen, utf8_decword_ptr, outlen); In your conv_to_utf8 you do printf() and print_hex(), the end-user is really not thta interested in what happens at the console. Perhaps use g_warning or g_critical if it's a really severe problem in the code, but a problem in the data of the user is never a problem of the application. In my opinion must problems about the data the application shows (the model) be reported to the user in the UI layer. Not on the console. On Mon, 2007-12-24 at 10:07 +0300, Peter Volkov wrote: > > And there are even more users affected by this. I've already reported > similar problem in bug 315513. Thus this affects not only CJK people: > > http://bugzilla.gnome.org/show_bug.cgi?id=315513 Okay, but this doesn't mean buffer overflowable code must be immediately accepted :), I guess we don't want ILY E-mails for the Linux desktop soon, right? -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers