This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
- From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 21 Jun 2011 12:09:50 +0000
- Subject: [Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
- Auto-submitted: auto-generated
- References: <bug-49314-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-06-21 12:09:30 UTC ---
> The question now is what's a clean fix for this issue, rather than
> hardcoding the result?
I've now checked this with native and GNU iconv: feff.utf-8 is the input
sequence from iconv_init:
> od -x feff.utf-8
0000000 bbef 0abf
At first everything seemed to work with both tools, except that I need
byte swapping with native iconv, but not with GNU iconv:
> /usr/bin/iconv -f UTF-8 -t UCS-2 < feff.utf-8 | od -x
0000000 feff 000a
> /vol/gnu/bin/iconv -f UTF-8 -t UCS-2 < feff.utf-8 | od -x
0000000 fffe 0a00
But when I removed the newline from the input file, results differ:
> od -x feff.utf-8-nonl
0000000 bbef 00bf
> /usr/bin/iconv -f UTF-8 -t UCS-2 < feff.utf-8-nonl | od -x
0000000 feff feff
> /vol/gnu/bin/iconv -f UTF-8 -t UCS-2 < feff.utf-8-nonl | od -x
0000000 fffe
As result, I've simply added a padding NUL byte to the input sequence.
This let the iconv succeed and my arraycopy testcase and both md5test
and shatest pass.
I'm running a full rebuild and check of libjava for good measure.
Rainer