'wchar_t' is not only locale dependent (i.e. run-time dependency) on a
single platform but also a compiler-dependent.
Yup. Isn't i18n fun?
It works because it relies
on iconv(3) to convert between the current locale codeset and UTF-16
(used internally by Mozilla) if/wherever possible. 'wc*to*mb/mb*to*wc'
is only used only where iconv(3) is not available. Anyway, yes, that's
possible. If a user mix multiple encodings/code sets in her/his file
system, that's not Perl's problem but her/his problem so that I don't
think that's a valid reason for not doing something reasonable.
Note that I'm not *opposed* to someone fixing e.g. Win32 being able to
acces Unicode names in NTFS/VFAT. What I'm opposed to is anyone
thinking
there are (a) easy (b) portable solutions. We are talking always of
very
OS and FS specific solutions. Win32 and Mac OS X are probably the most
"well-off". For (other) UNIXy systems, I don't know. If one is happy
with just using UTF-8 filenames, Perl 5.8 already can work fine. If one
wants to use locales and especially some non 8-bit locales, well, Perl
currently most definitely does not switch its "filename encoding" based
on locales. Personally I think that's a daft idea... at least without
a new specific (say) LC_FILENAME control-- overloading the poor LC_CTYPE
sounds dangerous.
Ed, if you think this is worth going forward, please do a little writeup
on this and start a discussion in perl5-porters. I am no more active in
the development, nor do I know much anything about Win32 APIs, Unicode
or
not, so I cannot be of much help.
--
Jarkko Hietaniemi <jhi(_at_)iki(_dot_)fi> http://www.iki.fi/jhi/ "There is this
special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
