[Mono-devel-list] filename character conversions(util/strenc.c)
Bernie Solomon
bernard at ugsolutions.com
Tue Nov 4 11:42:17 EST 2003
> glib should include iconv if your platform doesn't have it, I thought.
It actually configures itself depending on iconv's presence... I never
bothered
installing it (and HPUX doesn't have a native one).
>
> > Why does it explicitly translate to UTF16LE and not the host's
endianness?
> > If I use g_utf8_to_utf16 and not g_convert it appears to work better to
> > me on HP (at least GetCurrentDirectory does).
>
> UTF16 is what the CLR specifies for "Unicode", and as the MS runtime
> always seems to use LE (whether because it's x86-platform-endian or by
> choice) it makes sense to always use LE in mono. (Page 141 of my copy
> of Partition II mentions x86-endian storage for enum array elements of
> fixed args that are not bool or char. It doesn't seem to specify the
> endianness of unicode chars anywhere.)
This isn't how my big endian machines have been running and I can't really
see how we can make this work (unless we make every native type LE which
would be a big penalty). When would we make 'char' (which isn't a type in
MSIL anyway) byte swap as it becomes an integer type? Indeed at the MSIL
level short[] and char[] generate the same code (of course you can track
data types and probably work out which is which but that is a lot of work
and
in unverifiable code that would be impossible).
The only mention I can find of "endian" in Partition II is about data in the
assembly files - and that clearly has to be little endian - but I couldn't
find
anything about run-time data. I don't know what version your page
number is relative too - a section number would be better - I'm using the
word
doc in the SDK.
I can't see how we can't run in native endianess and that means chars
as well - this is how mono has run so far anyway.
So I'd like to change this to use g_utf8_to_utf16... but I guess we must
agree
on this endianess issue....
> I could have used ICU, but that would have made it a strict dependency
> not an optional one. As glib is already a strict dependency I chose to
> use that one. I suppose strenc.c could check for ICU and use that if
> possible.
This is less critical as I don't run with the new env var set anyway....
Bernie
More information about the Mono-devel-list
mailing list