This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114

--- Comment #4 from simon at pushface dot org ---
(In reply to Eric Botcazou from comment #2)

When I said in comment 1 

>I have to say that, great as it would be to have this fixed, the changes 
>required would be extensive, and I can’t see that anyone would think it 
>worth the trouble.

I meant that coping with macOS’s HFS+ behaviour w.r.t. NFC vs NFD was 
something it’d be unreasonable to spend effort on fixing.

The main point of this PR is that you can’t use extended characters in 
unit names on case-insensitive filesystems, *which includes Windows*. 
Fixing that problem (I can see it might mean introducing a new adaint.c 
interface "is filesystem UTF8?") would be a good thing. Can the compiler 
use iconv? or Ada.Wide_Characters.Handling,
Ada.Strings.UTF_Encoding.[Wide_]Strings?

The awkwardness discussed in comment 1 isn’t really a problem except 
when compiling the offending unit from the command line; when compiled 
as part of the closure by gnatmake there’s no problem, I guess gnatmake 
reads the unit name in NFC and gets the file name in NFD from the file 
system.

I think there _is_ a problem in gprbuild but of course that’s nothing 
to do with GCC.

Please can this PR be reopened?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]