In article <lyfszm5xv2.fsf@pushface.org>,
Simon Wright <simon@pushface.org> wrote:

> But don't use unit names containing international characters, at any
> rate if you're (interested in compiling on) Windows or macOS:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114

if i understand, Eric Botcazou is a gnu admin who decided to reject your bug?
i find him very "low portability thinking"!

it is the responsability of compilers and other underlying tools, to manage various underlying OS and FS,
not of the user to avoid those that the compiler devs find too bad!
(or to use the right encoding. i heard that Windows uses UTF-16, do you know about it?)

clearly, To_Lower takes Latin-1.
and this kind of problems would be easier to avoid if string types were stronger ...

after:

package Ada.Strings.UTF_Encoding
...
type UTF_8_String is new String;
...
end Ada.Strings.UTF_Encoding;

i would have also made:

package Ada.Directories
...
type File_Name_String is new Ada.Strings.UTF_Encoding.UTF_8_String;
...
end Ada.Directories;

with probably a validity check and a Dynamic_Predicate which allows "".

then, i would use File_Name_String in all Ada.Directories and Ada.*_IO.

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

On Sunday, April 3, 2022 at 10:20:21 PM UTC+3, Thomas wrote:
>
> > But don't use unit names containing international characters, at any
> > rate if you're (interested in compiling on) Windows or macOS:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
>
> and this kind of problems would be easier to avoid if string types were stronger ...
>

Your suggestion is unable to resolve this issue on Mac OS X. Like case sensitivity, binary compare of two strings can't compare strings in different normalization forms. Right solution is to use right type to represent any paths, and even it doesn't resolve some issues, like relative paths and change of rules at mounting points.

Vadim Godunko <vgodunko@gmail.com> writes:

> On Sunday, April 3, 2022 at 10:20:21 PM UTC+3, Thomas wrote:
>>
>> > But don't use unit names containing international characters, at
>> > any rate if you're (interested in compiling on) Windows or macOS:
>> >
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
>>
>> and this kind of problems would be easier to avoid if string types
>> were stronger ...
>>
>
> Your suggestion is unable to resolve this issue on Mac OS X. Like case
> sensitivity, binary compare of two strings can't compare strings in
> different normalization forms. Right solution is to use right type to
> represent any paths, and even it doesn't resolve some issues, like
> relative paths and change of rules at mounting points.

I think that's a macOS problem that Apple aren't going to resolve* any
time soon! While banging my head against PR81114 recently, I found
(can't remember where) that (lower case a acute) and (lower case a,
combining acute) represent the same concept and it's up to
tools/operating systems etc to recognise that.

Emacs, too, has a problem: it doesn't recognise the 'combining' part of
(lower case a, combining acute), so what you see on your screen is "a'".

* I don't know how/whether clang addresses this.

Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:

> In article <lyfszm5xv2.fsf@pushface.org>,
> Simon Wright <simon@pushface.org> wrote:
>
>> But don't use unit names containing international characters, at any
>> rate if you're (interested in compiling on) Windows or macOS:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
>
> if i understand, Eric Botcazou is a gnu admin who decided to reject
> your bug? i find him very "low portability thinking"!

To be fair, he only suspended it - you can tell I didn't want to press
very far.

We could remove the part where the filename is smashed to lower-case as
if it were ASCII[1][2][3] (OK, perhaps Latin-1?) if the machine is
Windows or (Apple if not on aarch64!!!), but that still leaves the
filesystem name issue. Windows might be OK (code pages???)

[1] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/adaint.c#L620
[2] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/lib-writ.adb#L812
[2] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/lib-writ.adb#L1490

Simon Wright <simon@pushface.org> writes:

> I think that's a macOS problem that Apple aren't going to resolve* any
> time soon! While banging my head against PR81114 recently, I found
> (can't remember where) that (lower case a acute) and (lower case a,
> combining acute) represent the same concept and it's up to
> tools/operating systems etc to recognise that.
[...]
> * I don't know how/whether clang addresses this.

It doesn't, so far as I can tell; has the exact same problem.

On Monday, April 4, 2022 at 5:19:20 PM UTC+3, Simon Wright wrote:
> I think that's a macOS problem that Apple aren't going to resolve* any
> time soon! While banging my head against PR81114 recently, I found
> (can't remember where) that (lower case a acute) and (lower case a,
> combining acute) represent the same concept and it's up to
> tools/operating systems etc to recognise that.
>
And will not. It is application responsibility to convert file names to NFD to pass to OS. Also, application must compare any paths after conversion to NFD, it is important to handle more complicated cases when canonical reordering is applied.

Vadim Godunko <vgodunko@gmail.com> writes:

> On Monday, April 4, 2022 at 5:19:20 PM UTC+3, Simon Wright wrote:
>> I think that's a macOS problem that Apple aren't going to resolve* any
>> time soon! While banging my head against PR81114 recently, I found
>> (can't remember where) that (lower case a acute) and (lower case a,
>> combining acute) represent the same concept and it's up to
>> tools/operating systems etc to recognise that.
>>
> And will not. It is application responsibility to convert file names
> to NFD to pass to OS. Also, application must compare any paths after
> conversion to NFD, it is important to handle more complicated cases
> when canonical reordering is applied.

Isn't the compiler a tool? gnatmake? gprbuild? (gnatmake handles ACATS
c250002 provided you tell the compiler that the fs is case-sensitive,
gprbuild doesn't even manage that)

sorry for the delay.

In article <48309745-aa2a-47bd-a4f9-6daa843e0771n@googlegroups.com>,
Vadim Godunko <vgodunko@gmail.com> wrote:

> On Sunday, April 3, 2022 at 10:20:21 PM UTC+3, Thomas wrote:
> >
> > > But don't use unit names containing international characters, at any
> > > rate if you're (interested in compiling on) Windows or macOS:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
> >
> > and this kind of problems would be easier to avoid if string types were
> > stronger ...
> >
>
> Your suggestion is unable to resolve this issue on Mac OS X.

i said "easier" not "easy".

don't forget that Unicode has 2 levels :
- octets <-> code points
- code points <-> characters/glyphs

and you can't expect the upper to work if the lower doesn't.

> Like case
> sensitivity, binary compare of two strings can't compare strings in different
> normalization forms. Right solution is to use right type to represent any
> paths,

what would be the "right type", according to you?

In fact, here the first question to ask is:
what's the expected encoding for Ada.Text_IO.Open.Name?
- is it Latin-1 because the type is String not UTF_8_String?
- is it undefined because it depends on the underling FS?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/