This problem is due to a bug in the encoding library.  I have attached a test program that
demonstrates that conversion is not always done correctly.

The attached test case in test.e creates a source encoding "646" and a destination
encoding "UTF-32".  It then converts three different strings to the destination
encoding and displays the results, showing the individual codes.  You can
see that the codes are ridiculously large numbers.

On Solaris 10, all three strings are converted incorrectly (see attached output_solaris10).
On Solaris 9, only the first string is converted incorrectly (see output_solaris9).

I stepped through {ENCODING_IMP}.convert_to and verified that on Solaris 9
there is no byte order mark (BOM) for the second and third conversions, though
I don't know why.

I believe the bug is that the code of the first character is passed to
`bom_little_endian' as a NATURAL_32.  If the first character is a BOM,
its value must be 0xFEFF so the comparison with 0xFEFF in
`bom_little_endian' will always be true, whether we're on a big endian or a little endian
platform.  I think there is a conceptual mistake here.  It seems to me that you
need to pass an address and compare specific bytes to determine whether
there is a BOM whose endianness does not match the current platform's endianness.

Please fix this so that we can get a usable version of 6.6.