138578 - Japanese to Unicode decoder has problem for its internal state

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[nhottanscp]

This was discovered when debuging bug 120728.
The conversion fails when calling the ISO-2022-JP converter in the loop.
The first called returns NS_OK_UDEC_MOREOUTPUT which is expected if the output
buffer is not large enough. But the second call returns NS_ERROR_UNEXPECTED when
the input is actually valid.

Comment 1

[Frank Tang]

In http://lxr.mozilla.org/seamonkey/source/intl/uconv/ucvja/nsJapaneseToUnicode.cpp
For all 3 converters, if we have goto error1; it mean there are no enough output
buffer. We already process the bytes, but we have not change the state . The
"mState =" should come before the goto statement. 

We think it is too risky to fix before m1.0 freeze. We need to fix this on trunk.

Comment 2

[Frank Tang]

if we want to change, we better change it before 1.2 alpha

Comment 3

[Jungshik Shin]

I'll make sure that this will be fixed by 1.8beta2.

Comment 4

[Jungshik Shin]

Attachment: patch

This does what ftang wrote he would. 

It fixes bug 263797 and my 5 minute test at the following sites didn't reveal
any flaw (well, that's not a thorough test, but it shuold be fine)

http://www.jp.analog.cx/ml/archive/ (ISO-2022-JP)
http://www.mozilla.gr.jp (EUC-JP)
http://www.asahi.co.jp (EUC-JP)
http://www.yomiuri.co.jp (Shift_JIS)
http://www.u-tokyo.ac.jp (Shift_JIS)

Comment 5

[[e-mail]]

Comment on attachment 175282 [details] [diff] [review]
patch

Sorry, I don't understand this code.

Comment 6

[Simon Montagu :smontagu]

Comment on attachment 175282 [details] [diff] [review]
patch

I remember once writing a patch to refactor this decoder, but it may never have
got attached to a bug, so it was probably lost in the AOL layoffs. Anyway, the
fix seems correct.

Comment 7

[Jungshik Shin]

thanks for r/sr. landed it.