http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jb at gcc dot gnu.org
--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-05-12 12:56:07
UTC ---
Wouldn't a standard-conforming way to support Unicode file names be for
gfortran to
- Specify that the default character set is UTF-8.
- Then an internal read or write could be used to do a UTF-8 <-> UTF-32
conversion, if the user program uses kind=4 characters. Or if the user program
stuffs utf-8 data into default character variables, nothing needs to be done.
- When passing a filename in the open statement, on posix this can be passed
as-is to open(), on mingw the library would need to do a utf-8 -> utf-16
conversion, then call wopen(). And similarly for other syscalls where we pass
path names (e.g. stat(), access() and so on).
In any case, initially something like your patch in #c1 looks good; regardless
of how/if we decide to support Unicode filenames, currently we don't do
anything sensible for kind=4 file names.
And as you say, it's a standard violation.
Similarly to specifying the default character set as UTF-8, we could specify
the default encoding as UTF-8 (see ENCODING= in OPEN (9.5.6.9) and INQUIRE
(9.10.2.10)). That way we wouldn't need to handle the non-Unicode cases in
10.7.1 at all. I think we're mostly there already, really, what's lacking is
perhaps a "GFortran and Unicode" chapter in the manual.
