diff mbox series

Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime

Message ID 47D204E3-3595-4A4A-A0C6-13AA83E95B13@pushface.org
State Accepted
Headers
Series Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime |

Checks

Context Check Description
snail/gcc-patch-check success Github commit url

Commit Message

Simon Wright Oct. 29, 2023, 11:51 a.m. UTC 
  This change affects only Ada.

In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the
assumption for __APPLE__ is that file names are case-insensitive
unless __arm__ or __arm64__ are defined, in which case file names
are declared case-sensitive.

The associated comment is
  "By default, we suppose filesystems aren't case sensitive on
  Windows and Darwin (but they are on arm-darwin)."

This means that on aarch64-apple-darwin, file names are declared
case-sensitive, which is not normally the case (but users can set
up case-sensitive volumes).

It's understood that GCC does not currently support iOS/tvOS/watchOS,
so we assume macOS.

Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression tested (check-gnat).
Also, tested with the example from PR ada/81114, extracted into 4 volumes (APFS, APFS-case-sensitive,
HFS, HFS-case-sensitive; the example code built successfully on the case-sensitive volumes.
Setting GNAT_FILE_NAME_CASE_SENSITIVE successfully overrode the choices made by the
new code.

 gcc/ada/Changelog:

 2023-10-29 Simon Wright <simon@pushface.org>

 PR ada/111909

 * gcc/ada/adaint.c
  (__gnat_get_file_names_case_sensitive): Remove the checks for
  __arm__, __arm64__.
  Split out the check for __APPLE__; remove the checks for __arm__,
  __arm64__, and use getattrlist(2) to determine whether the current
  working directory is on a case-sensitive filesystem.

Signed-off-by: Simon Wright <simon@pushface.org>
---
 gcc/ada/adaint.c | 46 ++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 42 insertions(+), 4 deletions(-)

Comments

Iain Sandoe Oct. 31, 2023, 8:07 a.m. UTC | #1 
Hi Simon,

(please cc me on Darwin-related patches)

> On 29 Oct 2023, at 11:51, Simon Wright <simon@pushface.org> wrote:
> 
> This change affects only Ada.
> 
> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the
> assumption for __APPLE__ is that file names are case-insensitive
> unless __arm__ or __arm64__ are defined, in which case file names
> are declared case-sensitive.
> 
> The associated comment is
>  "By default, we suppose filesystems aren't case sensitive on
>  Windows and Darwin (but they are on arm-darwin)."
> 
> This means that on aarch64-apple-darwin, file names are declared
> case-sensitive, which is not normally the case (but users can set
> up case-sensitive volumes).
> 
> It's understood that GCC does not currently support iOS/tvOS/watchOS,
> so we assume macOS.
> 
> Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression tested (check-gnat).
> Also, tested with the example from PR ada/81114, extracted into 4 volumes (APFS, APFS-case-sensitive,
> HFS, HFS-case-sensitive; the example code built successfully on the case-sensitive volumes.
> Setting GNAT_FILE_NAME_CASE_SENSITIVE successfully overrode the choices made by the
> new code.

This does not yet work on at least Darwin17 and Darwin9, even though the ‘getattrlist()` call
and the `VOL_CAP_FMT_CASE_SENSITIVE` should exist on both.  So we need to figure
out why the current code is not working (so, not yet OK from a Darwin perspective).

thanks
Iain

> 
> gcc/ada/Changelog:
> 
> 2023-10-29 Simon Wright <simon@pushface.org>
> 
> PR ada/111909
> 
> * gcc/ada/adaint.c
>  (__gnat_get_file_names_case_sensitive): Remove the checks for
>  __arm__, __arm64__.
>  Split out the check for __APPLE__; remove the checks for __arm__,
>  __arm64__, and use getattrlist(2) to determine whether the current
>  working directory is on a case-sensitive filesystem.
> 
> Signed-off-by: Simon Wright <simon@pushface.org>
> ---
> gcc/ada/adaint.c | 46 ++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 42 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
> index 2a193efc002..43d166824b0 100644
> --- a/gcc/ada/adaint.c
> +++ b/gcc/ada/adaint.c
> @@ -85,6 +85,7 @@
> 
> #if defined (__APPLE__)
> #include <unistd.h>
> +#include <sys/attr.h>
> #endif
> 
> #if defined (__hpux__)
> @@ -613,11 +614,48 @@ __gnat_get_file_names_case_sensitive (void)
>       else
> 	{
> 	  /* By default, we suppose filesystems aren't case sensitive on
> -	     Windows and Darwin (but they are on arm-darwin).  */
> -#if defined (WINNT) || defined (__DJGPP__) \
> -  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
> +	     Windows or DOS.  */
> +#if defined (WINNT) || defined (__DJGPP__)
> 	  file_names_case_sensitive_cache = 0;
> -#else
> +#elif defined (__APPLE__)
> +	  /* Determine whether the current volume is case-sensitive.  */
> +	  {
> +	    /* Formulate a query for the volume capabilities.  */
> +	    struct attrlist attrList
> +	      = {ATTR_BIT_MAP_COUNT,
> +		 0,				      /* reserved.  */
> +		 0,				      /* commonattr.  */
> +		 ATTR_VOL_INFO | ATTR_VOL_CAPABILITIES, /* volattr.  */
> +		 0,				      /* dirattr.  */
> +		 0,				      /* fileattr.  */
> +		 0				      /* forkattr.  */
> +		};
> +
> +	    /* A buffer to contain just the volume capabilities.  */
> +	    struct returnBuf {
> +	      u_int32_t length;
> +	      vol_capabilities_attr_t caps;
> +	    } __attribute__ ((aligned (4), packed)) retBuf;
> +
> +	    /* Default to case-insensitive.  */
> +	    file_names_case_sensitive_cache = 0;
> +
> +	    /* Query the current working directory.  */
> +	    if (getattrlist (".",
> +			     &attrList,
> +			     &retBuf,
> +			     sizeof (retBuf),
> +			     0) == 0)
> +	      /* The call succeeded.  */
> +	      if ((retBuf.caps.valid[VOL_CAPABILITIES_FORMAT]
> +		   & VOL_CAP_FMT_CASE_SENSITIVE))
> +		/* The volume could be case-sensitive.  */
> +		if (retBuf.caps.capabilities[VOL_CAPABILITIES_FORMAT]
> +		    & VOL_CAP_FMT_CASE_SENSITIVE)
> +		  /* The volume is case-sensitive.  */
> +		  file_names_case_sensitive_cache = 1;
> +	  }
> +#else /* Neither Windows nor Apple.  */
> 	  file_names_case_sensitive_cache = 1;
> #endif
> 	}
> -- 
> 2.39.3 (Apple Git-145)
>
Arnaud Charlet Nov. 3, 2023, 8:39 a.m. UTC | #2 
Hi Simon,

In addition to the non portable issues already mentioned, this change isn't OK also
for other reasons.

Basically this function is global and decides once for all on the case sensitivity, while
the case sensitiviy is on a per filsystem basis as you noted.

So without changing fundamentally the model, you can't decide dynamically for the whole
system. Making the choice based on the current directory is pretty random, since the current
directory isn't well defined at program's start up and could be pretty much any filesystem.

Note that the current setting on arm is actually for iOS, which we did support at AdaCore
at some point (and could revive in the future, who knows).

So it would be fine to refine the test to differentiate between macOS and embedded iOS and co,
that would be a better change here.

> This change affects only Ada.
> 
> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the
> assumption for __APPLE__ is that file names are case-insensitive
> unless __arm__ or __arm64__ are defined, in which case file names
> are declared case-sensitive.
> 
> The associated comment is
>   "By default, we suppose filesystems aren't case sensitive on
>   Windows and Darwin (but they are on arm-darwin)."
> 
> This means that on aarch64-apple-darwin, file names are declared
> case-sensitive, which is not normally the case (but users can set
> up case-sensitive volumes).
> 
> It's understood that GCC does not currently support iOS/tvOS/watchOS,
> so we assume macOS.
> 
> Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression tested (check-gnat).
> Also, tested with the example from PR ada/81114, extracted into 4 volumes (APFS, APFS-case-sensitive,
> HFS, HFS-case-sensitive; the example code built successfully on the case-sensitive volumes.
> Setting GNAT_FILE_NAME_CASE_SENSITIVE successfully overrode the choices made by the
> new code.
> 
>  gcc/ada/Changelog:
> 
>  2023-10-29 Simon Wright <simon@pushface.org>
> 
>  PR ada/111909
> 
>  * gcc/ada/adaint.c
>   (__gnat_get_file_names_case_sensitive): Remove the checks for
>   __arm__, __arm64__.
>   Split out the check for __APPLE__; remove the checks for __arm__,
>   __arm64__, and use getattrlist(2) to determine whether the current
>   working directory is on a case-sensitive filesystem.
> 
> Signed-off-by: Simon Wright <simon@pushface.org>
Simon Wright Nov. 4, 2023, 5:02 p.m. UTC | #3 
On 3 Nov 2023, at 08:39, Arnaud Charlet <charlet@adacore.com> wrote:

> In addition to the non portable issues already mentioned, this change isn't OK also
> for other reasons.
> 
> Basically this function is global and decides once for all on the case sensitivity, while
> the case sensitiviy is on a per filsystem basis as you noted.

Well, the current code does exactly what you describe, with less relationship to the actual 
environment than this proposal.

> So without changing fundamentally the model, you can't decide dynamically for the whole
> system. Making the choice based on the current directory is pretty random, since the current
> directory isn't well defined at program's start up and could be pretty much any filesystem.

I’d imagine that projects spread over more than one differently-case-sensitive filesystem would
be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so
likely to be somewhere near the project’s source tree.

> Note that the current setting on arm is actually for iOS, which we did support at AdaCore
> at some point (and could revive in the future, who knows).

Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently
supported by GCC.

> So it would be fine to refine the test to differentiate between macOS and embedded iOS and co,
> that would be a better change here.

There didn’t seem to be a way to do that.

But anyway, I find myself puzzled by the casing issue. It seems to me that on a CS filesystem
users would be well advised to stick to lower-case filenames, or the compiler won’t be able to
resolve 'with' statements; whereas on a non-CS system, there’d be no such constraint. Indeed,
when compiling a file with a mixed-case name in a CS environment, the compiler warns:

$ GNAT_FILE_NAME_CASE_SENSITIVE=1 gcc -c -u -f WTF.adb
WTF.adb:1:11: warning: file name does not match unit name, should be "wtf.adb" [enabled by default]

Also, there’ve been about 80 downloads of GCC 13.1.0 for aarch64-apple-darwin, and no 
case-sensitivity issues have been reported.

So, Iain, do we want to pursue this?

> 
>> This change affects only Ada.
>> 
>> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the
>> assumption for __APPLE__ is that file names are case-insensitive
>> unless __arm__ or __arm64__ are defined, in which case file names
>> are declared case-sensitive.
>> 
>> The associated comment is
>>  "By default, we suppose filesystems aren't case sensitive on
>>  Windows and Darwin (but they are on arm-darwin)."
>> 
>> This means that on aarch64-apple-darwin, file names are declared
>> case-sensitive, which is not normally the case (but users can set
>> up case-sensitive volumes).
>> 
>> It's understood that GCC does not currently support iOS/tvOS/watchOS,
>> so we assume macOS.
>> 
>> Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression tested (check-gnat).
>> Also, tested with the example from PR ada/81114, extracted into 4 volumes (APFS, APFS-case-sensitive,
>> HFS, HFS-case-sensitive; the example code built successfully on the case-sensitive volumes.
>> Setting GNAT_FILE_NAME_CASE_SENSITIVE successfully overrode the choices made by the
>> new code.
>> 
>> gcc/ada/Changelog:
>> 
>> 2023-10-29 Simon Wright <simon@pushface.org>
>> 
>> PR ada/111909
>> 
>> * gcc/ada/adaint.c
>>  (__gnat_get_file_names_case_sensitive): Remove the checks for
>>  __arm__, __arm64__.
>>  Split out the check for __APPLE__; remove the checks for __arm__,
>>  __arm64__, and use getattrlist(2) to determine whether the current
>>  working directory is on a case-sensitive filesystem.
>> 
>> Signed-off-by: Simon Wright <simon@pushface.org>
Iain Sandoe Nov. 4, 2023, 11:28 p.m. UTC | #4 
Hi Folks

> On 4 Nov 2023, at 17:02, Simon Wright <simon@pushface.org> wrote:
> 
> On 3 Nov 2023, at 08:39, Arnaud Charlet <charlet@adacore.com> wrote:

>> So without changing fundamentally the model, you can't decide dynamically for the whole
>> system. Making the choice based on the current directory is pretty random, since the current
>> directory isn't well defined at program's start up and could be pretty much any filesystem.
> 
> I’d imagine that projects spread over more than one differently-case-sensitive filesystem would
> be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so
> likely to be somewhere near the project’s source tree.

It’s likely much less rare to find a CS external disk or an NFS mount, or secondary FS with a non-CS system partition,
(since the default for the system install is that way).

I am suspicious of second-guessing any of this; my opinion is that if we have an automated
recognition of CS, then it needs to work in the general circumstance (that would certainly be in the
spirit of macOS “it just works”).

If we cannot achieve that, the advantage of the current scenario (GNAT_FILE_NAME_CASE_SENSITIVE=..)
is that it is explicit on the part of the user, and therefore puts the onus on the user to get it right.

>> Note that the current setting on arm is actually for iOS, which we did support at AdaCore
>> at some point (and could revive in the future, who knows).
> 
> Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently
> supported by GCC.

Historically, we had no support for Arm or AArch64, so the missing support of iOS as a concept was
not important - now we have an AArch64 port, it is feasible and potentially relevant to update this.

Having said that, I’m not sure how a a GCC-developed iOS app would be distributed - but of course
libraries are a different story.
> 
>> So it would be fine to refine the test to differentiate between macOS and embedded iOS and co,
>> that would be a better change here.
> 
> There didn’t seem to be a way to do that.

We should be able to do that at runtime (sysctl calls for example)

> So, Iain, do we want to pursue this?


Right now, I have no spare resources to tackle this, (I suspect that the issues I see on earlier systems
are due to the syscall not finding the right root FS from paths like /foo/bar so it remains to be see how
to deal with it).  I have no objection from a Darwin perspective to folks finding a mutually agreeable 
solution that works without the user specifying the env. var - but I’m not going to be able to contribute
much to the work in the near future.

thanks
Iain
Arnaud Charlet Nov. 6, 2023, 8:36 a.m. UTC | #5 
> > So without changing fundamentally the model, you can't decide dynamically for the whole
> > system. Making the choice based on the current directory is pretty random, since the current
> > directory isn't well defined at program's start up and could be pretty much any filesystem.
> 
> I’d imagine that projects spread over more than one differently-case-sensitive filesystem would
> be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so
> likely to be somewhere near the project’s source tree.

I am not talking about the current directory when the compiler runs, I am talking about the
current directory where the target program runs, which can be pretty much anywhere.

In other words, you are modifying a runtime file (adaint.c) which is used both by the host compiler
and by the target applications. My comment worries about the target applications while yours
applies to the host compiler only.

> > Note that the current setting on arm is actually for iOS, which we did support at AdaCore
> > at some point (and could revive in the future, who knows).
> 
> Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently
> supported by GCC.

That's another option. We'd like to keep both options on the table, since both options have
pros and cons.

> > So it would be fine to refine the test to differentiate between macOS and embedded iOS and co,
> > that would be a better change here.
> 
> There didn’t seem to be a way to do that.

OK, I thought there would be some defines that we could use for that, too bad if there isn't
and indeed we might need to perform another runtime check then as suggested by Iain.

Arno
Simon Wright Nov. 11, 2023, 5:47 p.m. UTC | #6 
On 6 Nov 2023, at 08:36, Arnaud Charlet <charlet@adacore.com> wrote:
> 
>>> So without changing fundamentally the model, you can't decide dynamically for the whole
>>> system. Making the choice based on the current directory is pretty random, since the current
>>> directory isn't well defined at program's start up and could be pretty much any filesystem.
>> 
>> I’d imagine that projects spread over more than one differently-case-sensitive filesystem would
>> be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so
>> likely to be somewhere near the project’s source tree.
> 
> I am not talking about the current directory when the compiler runs, I am talking about the
> current directory where the target program runs, which can be pretty much anywhere.
> 
> In other words, you are modifying a runtime file (adaint.c) which is used both by the host compiler
> and by the target applications. My comment worries about the target applications while yours
> applies to the host compiler only.

I don’t understand?

The change works out whether the filesystem of the current working directory is CS, whether
 it’s the compiler or some user program that’s running it (it looks like that would have to be via 
some higher-level compiler package, I found only GNAT.Command_Line and 
GNAT.Directory_Operations).

I can see that might not be what the user program wants, but if they actually care the current
situation isn’t great anyway; the compiler definitely makes the wrong choice for new Macs.

>>> Note that the current setting on arm is actually for iOS, which we did support at AdaCore
>>> at some point (and could revive in the future, who knows).
>> 
>> Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently
>> supported by GCC.
> 
> That's another option. We'd like to keep both options on the table, since both options have
> pros and cons.
> 
>>> So it would be fine to refine the test to differentiate between macOS and embedded iOS and co,
>>> that would be a better change here.
>> 
>> There didn’t seem to be a way to do that.
> 
> OK, I thought there would be some defines that we could use for that, too bad if there isn't
> and indeed we might need to perform another runtime check then as suggested by Iain.

I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - Objective C
needed, I think

> Arno
Iain Sandoe Nov. 11, 2023, 6:10 p.m. UTC | #7 
> On 11 Nov 2023, at 07:47, Simon Wright <simon@pushface.org> wrote:
> 
> On 6 Nov 2023, at 08:36, Arnaud Charlet <charlet@adacore.com> wrote:
>> 
>>>> So without changing fundamentally the model, you can't decide dynamically for the whole
>>>> system. Making the choice based on the current directory is pretty random, since the current
>>>> directory isn't well defined at program's start up and could be pretty much any filesystem.
>>> 
>>> I’d imagine that projects spread over more than one differently-case-sensitive filesystem would
>>> be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so
>>> likely to be somewhere near the project’s source tree.
>> 
>> I am not talking about the current directory when the compiler runs, I am talking about the
>> current directory where the target program runs, which can be pretty much anywhere.
>> 
>> In other words, you are modifying a runtime file (adaint.c) which is used both by the host compiler
>> and by the target applications. My comment worries about the target applications while yours
>> applies to the host compiler only.
> 
> I don’t understand?
> 
> The change works out whether the filesystem of the current working directory is CS, whether
> it’s the compiler or some user program that’s running it (it looks like that would have to be via 
> some higher-level compiler package, I found only GNAT.Command_Line and 
> GNAT.Directory_Operations).
> 
> I can see that might not be what the user program wants, but if they actually care the current
> situation isn’t great anyway; the compiler definitely makes the wrong choice for new Macs.
> 
>>>> Note that the current setting on arm is actually for iOS, which we did support at AdaCore
>>>> at some point (and could revive in the future, who knows).
>>> 
>>> Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently
>>> supported by GCC.
>> 
>> That's another option. We'd like to keep both options on the table, since both options have
>> pros and cons.
>> 
>>>> So it would be fine to refine the test to differentiate between macOS and embedded iOS and co,
>>>> that would be a better change here.
>>> 
>>> There didn’t seem to be a way to do that.
>> 
>> OK, I thought there would be some defines that we could use for that, too bad if there isn't
>> and indeed we might need to perform another runtime check then as suggested by Iain.
> 
> I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - Objective C
> needed, I think

Some of the NS interfaces are available to regular C (e.g. stuff in CoreFoundation), and I am
fairly/very sure that we will be able to find a machanism that does not involve introducing an
ObjC dep.  [I am obvioulsy not in any way against ObjC - since i’m the maintainer ;) .. but it
seems heavyweight for solving this issue].

Iain
Simon Wright Nov. 13, 2023, 4:03 p.m. UTC | #8 
On 11 Nov 2023, at 18:10, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
>> On 11 Nov 2023, at 07:47, Simon Wright <simon@pushface.org> wrote:
>> 
>> On 6 Nov 2023, at 08:36, Arnaud Charlet <charlet@adacore.com> wrote:
>>> 
>>>>> So without changing fundamentally the model, you can't decide dynamically for the whole
>>>>> system. Making the choice based on the current directory is pretty random, since the current
>>>>> directory isn't well defined at program's start up and could be pretty much any filesystem.
>>>> 
>>>> I’d imagine that projects spread over more than one differently-case-sensitive filesystem would
>>>> be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so
>>>> likely to be somewhere near the project’s source tree.
>>> 
>>> I am not talking about the current directory when the compiler runs, I am talking about the
>>> current directory where the target program runs, which can be pretty much anywhere.
>>> 
>>> In other words, you are modifying a runtime file (adaint.c) which is used both by the host compiler
>>> and by the target applications. My comment worries about the target applications while yours
>>> applies to the host compiler only.
>> 
>> I don’t understand?
>> 
>> The change works out whether the filesystem of the current working directory is CS, whether
>> it’s the compiler or some user program that’s running it (it looks like that would have to be via 
>> some higher-level compiler package, I found only GNAT.Command_Line and 
>> GNAT.Directory_Operations).
>> 
>> I can see that might not be what the user program wants, but if they actually care the current
>> situation isn’t great anyway; the compiler definitely makes the wrong choice for new Macs.
>> 
>>>>> Note that the current setting on arm is actually for iOS, which we did support at AdaCore
>>>>> at some point (and could revive in the future, who knows).
>>>> 
>>>> Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently
>>>> supported by GCC.
>>> 
>>> That's another option. We'd like to keep both options on the table, since both options have
>>> pros and cons.
>>> 
>>>>> So it would be fine to refine the test to differentiate between macOS and embedded iOS and co,
>>>>> that would be a better change here.
>>>> 
>>>> There didn’t seem to be a way to do that.
>>> 
>>> OK, I thought there would be some defines that we could use for that, too bad if there isn't
>>> and indeed we might need to perform another runtime check then as suggested by Iain.
>> 
>> I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - Objective C
>> needed, I think
> 
> Some of the NS interfaces are available to regular C (e.g. stuff in CoreFoundation), and I am
> fairly/very sure that we will be able to find a machanism that does not involve introducing an
> ObjC dep.  [I am obvioulsy not in any way against ObjC - since i’m the maintainer ;) .. but it
> seems heavyweight for solving this issue].

It certainly would be heavyweight, since TargetConditionals.h includes TARGET_OS_OSX, 
which is 1 if we’re compiling for macOS and 0 otherwise (there’s a useful chart at :83 in the 
MacOSX13.1 SDK).

Two ways ahead here:
(1) just replace the current __arm__, __arm64__ test with this
(2) as 1, but implement the runtime test for case sensitivity only for macOS

Whether (2) is acceptable depends, I suppose, on what issues Iain encountered on Darwin 9 
& Darwin 17. I’ll be content to go with (1).
Arnaud Charlet Nov. 13, 2023, 4:18 p.m. UTC | #9 
> >>> OK, I thought there would be some defines that we could use for that, too bad if there isn't
> >>> and indeed we might need to perform another runtime check then as suggested by Iain.
> >> 
> >> I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - Objective C
> >> needed, I think
> > 
> > Some of the NS interfaces are available to regular C (e.g. stuff in CoreFoundation), and I am
> > fairly/very sure that we will be able to find a machanism that does not involve introducing an
> > ObjC dep.  [I am obvioulsy not in any way against ObjC - since i’m the maintainer ;) .. but it
> > seems heavyweight for solving this issue].
> 
> It certainly would be heavyweight, since TargetConditionals.h includes TARGET_OS_OSX, 
> which is 1 if we’re compiling for macOS and 0 otherwise (there’s a useful chart at :83 in the 
> MacOSX13.1 SDK).
> 
> Two ways ahead here:
> (1) just replace the current __arm__, __arm64__ test with this

That would be fine here (replace refs to *arm* by TARGET_OS_OSX), since this was my original
suggestion (copied at the top of this email).

> (2) as 1, but implement the runtime test for case sensitivity only for macOS
> 
> Whether (2) is acceptable depends, I suppose, on what issues Iain encountered on Darwin 9 
> & Darwin 17. I’ll be content to go with (1).
Simon Wright Nov. 16, 2023, 8:56 p.m. UTC | #10 
On 13 Nov 2023, at 16:18, Arnaud Charlet <charlet@adacore.com> wrote:
> 
>>>>> OK, I thought there would be some defines that we could use for that, too bad if there isn't
>>>>> and indeed we might need to perform another runtime check then as suggested by Iain.
>>>> 
>>>> I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - Objective C
>>>> needed, I think
>>> 
>>> Some of the NS interfaces are available to regular C (e.g. stuff in CoreFoundation), and I am
>>> fairly/very sure that we will be able to find a machanism that does not involve introducing an
>>> ObjC dep.  [I am obvioulsy not in any way against ObjC - since i’m the maintainer ;) .. but it
>>> seems heavyweight for solving this issue].
>> 
>> It certainly would be heavyweight, since TargetConditionals.h includes TARGET_OS_OSX, 
>> which is 1 if we’re compiling for macOS and 0 otherwise (there’s a useful chart at :83 in the 
>> MacOSX13.1 SDK).
>> 
>> Two ways ahead here:
>> (1) just replace the current __arm__, __arm64__ test with this
> 
> That would be fine here (replace refs to *arm* by TARGET_OS_OSX), since this was my original
> suggestion (copied at the top of this email).
> 
>> (2) as 1, but implement the runtime test for case sensitivity only for macOS
>> 
>> Whether (2) is acceptable depends, I suppose, on what issues Iain encountered on Darwin 9 
>> & Darwin 17. I’ll be content to go with (1).

I'm not sure whether this should have been a new [PATCH V2] thread?

Also, should the test code below (between %%%) be included in the
testsuite?

--8<--

In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the
current assumption for __APPLE__ is that file names are
case-insensitive unless __arm__ or __arm64__ are defined, in which
case file names are declared case-sensitive.

The associated comment is
  "By default, we suppose filesystems aren't case sensitive on
  Windows and Darwin (but they are on arm-darwin)."

This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.

Apple provide a header file <TargetConditionals.h> which permits a
compile-time check for the compiler target (e.g. OSX vs IOS). At Darwin
10.5 (Xcode 3) iOS wasn't supported, so it was adequate to check
TARGET_OS_MAC; nowadays, that covers many variants including macOS
and iOS, so one needs to check whether TARGET_OS_OSX is defined, and
if so whether it's set.

Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression
tested (check-ada).

Likewise bootstrapped on aarch64-apple-darwin from the Github sources
corresponding to GCC 2023-11-05.

__gnat_get_file_names_case_sensitive() isn't exported to user code, so
implemented check code as below: each compiler (x86_64-apple-darwin and
aarch64-apple-darwin) reported that file names were not case sensitive.

%%%
with Ada.Text_IO;
with Interfaces.C;
procedure Check_Case_Sensitivity is
   type C_Boolean is (False, True)
     with Convention => C;
   function Get_File_Names_Case_Sensitive return C_Boolean
   with
     Import,
     Convention => C,
     External_Name => "__gnat_get_file_names_case_sensitive";
begin
   Ada.Text_IO.Put_Line ("GNAT thinks file names are " &
                           (case Get_File_Names_Case_Sensitive is
                               when False => "not case sensitive",
                               when True  => "case sensitive"));
end Check_Case_Sensitivity;
%%%

gcc/ada/Changelog:

2023-11-16 Simon Wright <simon@pushface.org>

  * gcc/ada/adaint.c
  (__gnat_get_file_names_case_sensitive): Split out the __APPLE__
  check and remove the checks for __arm__, __arm64__.
  File names are by default case sensitive unless TARGET_OS_OSX
  (or if this is an older OS release, in which case TARGET_OS_OSX
  is undefined, TARGET_OS_MAC) is set.

Signed-off-by: Simon Wright <simon@pushface.org>
---
 gcc/ada/adaint.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index bb4ed2607e5..1ef529ec20b 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -84,7 +84,7 @@
 #endif /* VxWorks */
 
 #if defined (__APPLE__)
-#include <unistd.h>
+#include <TargetConditionals.h>
 #endif
 
 #if defined (__hpux__)
@@ -613,12 +613,25 @@ __gnat_get_file_names_case_sensitive (void)
       else
 	{
 	  /* By default, we suppose filesystems aren't case sensitive on
-	     Windows and Darwin (but they are on arm-darwin).  */
-#if defined (WINNT) || defined (__DJGPP__) \
-  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
+	     Windows or DOS.  */
+#if defined (WINNT) || defined (__DJGPP__)
+	  file_names_case_sensitive_cache = 0;
+#elif defined (__APPLE__)
+	  /* By default, macOS volumes are case-insensitive, iOS
+	     volumes are case-sensitive.  */
+#if defined (TARGET_OS_OSX)      /* In recent SDK.  */
+#if TARGET_OS_OSX                /* macOS.  */   
 	  file_names_case_sensitive_cache = 0;
 #else
 	  file_names_case_sensitive_cache = 1;
+#endif
+#elif TARGET_OS_MAC    /* macOS, in older SDK.  */
+	  file_names_case_sensitive_cache = 0;
+#else
+	  file_names_case_sensitive_cache = 1;
+#endif
+#else /* Neither Windows nor Apple.  */
+	  file_names_case_sensitive_cache = 1;
 #endif
 	}
     }
Arnaud Charlet Nov. 17, 2023, 8:37 a.m. UTC | #11 
> Also, should the test code below (between %%%) be included in the
> testsuite?

It would be good but tests shouldn't output anything, they should be self testing,
and you will need to deal with making the test portable to all targets.

Given that the compiler itself uses this feature, I don't think this is worth
the trouble.

> @@ -613,12 +613,25 @@ __gnat_get_file_names_case_sensitive (void)
>        else
>  	{
>  	  /* By default, we suppose filesystems aren't case sensitive on
> -	     Windows and Darwin (but they are on arm-darwin).  */
> -#if defined (WINNT) || defined (__DJGPP__) \
> -  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
> +	     Windows or DOS.  */
> +#if defined (WINNT) || defined (__DJGPP__)
> +	  file_names_case_sensitive_cache = 0;
> +#elif defined (__APPLE__)
> +	  /* By default, macOS volumes are case-insensitive, iOS
> +	     volumes are case-sensitive.  */
> +#if defined (TARGET_OS_OSX)      /* In recent SDK.  */
> +#if TARGET_OS_OSX                /* macOS.  */   
>  	  file_names_case_sensitive_cache = 0;
>  #else
>  	  file_names_case_sensitive_cache = 1;
> +#endif
> +#elif TARGET_OS_MAC    /* macOS, in older SDK.  */
> +	  file_names_case_sensitive_cache = 0;
> +#else
> +	  file_names_case_sensitive_cache = 1;
> +#endif
> +#else /* Neither Windows nor Apple.  */
> +	  file_names_case_sensitive_cache = 1;
>  #endif

Please simplify the above to (untested):

 #elif defined (__APPLE__)
        /* By default, macOS volumes are case-insensitive, iOS
           volumes are case-sensitive.  */
 #if TARGET_OS_MAC    /* macOS, in older SDK.  */
         file_names_case_sensitive_cache = 0;
 #elif TARGET_OS_OSX  /* macOS, in recent SDK.  */
         file_names_case_sensitive_cache = 0;
 #else                /* assume iOS.  */
         file_names_case_sensitive_cache = 1;
 #endif
 #else /* Neither Windows nor Apple.  */
	 file_names_case_sensitive_cache = 1;
 #endif

which is simpler and more readable and should be equivalent AFAICT.

OK with the above change.

Arno
Simon Wright Nov. 17, 2023, 9:06 a.m. UTC | #12 
On 17 Nov 2023, at 08:37, Arnaud Charlet <charlet@adacore.com> wrote:
> 
>> Also, should the test code below (between %%%) be included in the
>> testsuite?
> 
> It would be good but tests shouldn't output anything, they should be self testing,
> and you will need to deal with making the test portable to all targets.
> 
> Given that the compiler itself uses this feature, I don't think this is worth
> the trouble.

OK

>> @@ -613,12 +613,25 @@ __gnat_get_file_names_case_sensitive (void)
>>       else
>> 	{
>> 	  /* By default, we suppose filesystems aren't case sensitive on
>> -	     Windows and Darwin (but they are on arm-darwin).  */
>> -#if defined (WINNT) || defined (__DJGPP__) \
>> -  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
>> +	     Windows or DOS.  */
>> +#if defined (WINNT) || defined (__DJGPP__)
>> +	  file_names_case_sensitive_cache = 0;
>> +#elif defined (__APPLE__)
>> +	  /* By default, macOS volumes are case-insensitive, iOS
>> +	     volumes are case-sensitive.  */
>> +#if defined (TARGET_OS_OSX)      /* In recent SDK.  */
>> +#if TARGET_OS_OSX                /* macOS.  */   
>> 	  file_names_case_sensitive_cache = 0;
>> #else
>> 	  file_names_case_sensitive_cache = 1;
>> +#endif
>> +#elif TARGET_OS_MAC    /* macOS, in older SDK.  */
>> +	  file_names_case_sensitive_cache = 0;
>> +#else
>> +	  file_names_case_sensitive_cache = 1;
>> +#endif
>> +#else /* Neither Windows nor Apple.  */
>> +	  file_names_case_sensitive_cache = 1;
>> #endif
> 
> Please simplify the above to (untested):
> 
> #elif defined (__APPLE__)
>        /* By default, macOS volumes are case-insensitive, iOS
>           volumes are case-sensitive.  */
> #if TARGET_OS_MAC    /* macOS, in older SDK.  */
>         file_names_case_sensitive_cache = 0;
> #elif TARGET_OS_OSX  /* macOS, in recent SDK.  */
>         file_names_case_sensitive_cache = 0;
> #else                /* assume iOS.  */
>         file_names_case_sensitive_cache = 1;
> #endif
> #else /* Neither Windows nor Apple.  */
> 	 file_names_case_sensitive_cache = 1;
> #endif
> 
> which is simpler and more readable and should be equivalent AFAICT.
> 
> OK with the above change.
> 
> Arno

Sorry, but that wouldn’t work.

TargetConditionals.h is created by Apple as part of SDK construction, so the TARGET_* macros are defined directly (#define TARGET_OS_OSX 1),

In a newer macOS SDK, both TARGET_OS_MAC and TARGET_OS_OSX are defined and set to 1, and TARGET_OS_MAC covers OSX (macOS), IOS, TV, WATCH and others.
In an older macOS SDK, TARGET_OS_MAC is defined and set to 1, and none of the others are defined at all.

This is from the current TargetConditionals.h:

 *    +---------------------------------------------------------------------------+
 *    |                             TARGET_OS_MAC                                 |
 *    | +-----+ +-------------------------------------------------+ +-----------+ |
 *    | |     | |                  TARGET_OS_IPHONE               | |           | |
 *    | |     | | +-----------------+ +----+ +-------+ +--------+ | |           | |
 *    | |     | | |       IOS       | |    | |       | |        | | |           | |
 *    | | OSX | | | +-------------+ | | TV | | WATCH | | BRIDGE | | | DRIVERKIT | |
 *    | |     | | | | MACCATALYST | | |    | |       | |        | | |           | |
 *    | |     | | | +-------------+ | |    | |       | |        | | |           | |
 *    | |     | | +-----------------+ +----+ +-------+ +--------+ | |           | |
 *    | +-----+ +-------------------------------------------------+ +-----------+ |
 *    +---------------------------------------------------------------------------+
Arnaud Charlet Nov. 17, 2023, 9:29 a.m. UTC | #13 
> > Please simplify the above to (untested):
> > 
> > #elif defined (__APPLE__)
> >        /* By default, macOS volumes are case-insensitive, iOS
> >           volumes are case-sensitive.  */
> > #if TARGET_OS_MAC    /* macOS, in older SDK.  */
> >         file_names_case_sensitive_cache = 0;
> > #elif TARGET_OS_OSX  /* macOS, in recent SDK.  */
> >         file_names_case_sensitive_cache = 0;
> > #else                /* assume iOS.  */
> >         file_names_case_sensitive_cache = 1;
> > #endif
> > #else /* Neither Windows nor Apple.  */
> > 	 file_names_case_sensitive_cache = 1;
> > #endif
> > 
> > which is simpler and more readable and should be equivalent AFAICT.
> > 
> > OK with the above change.
> > 
> > Arno
> 
> Sorry, but that wouldn’t work.

Then invert the two first tests, that doesn't change the gist of my suggestion to simplify the
tests.

> TargetConditionals.h is created by Apple as part of SDK construction, so the TARGET_* macros are defined directly (#define TARGET_OS_OSX 1),
> 
> In a newer macOS SDK, both TARGET_OS_MAC and TARGET_OS_OSX are defined and set to 1, and TARGET_OS_MAC covers OSX (macOS), IOS, TV, WATCH and others.
> In an older macOS SDK, TARGET_OS_MAC is defined and set to 1, and none of the others are defined at all.
Simon Wright Nov. 17, 2023, 12:53 p.m. UTC | #14 
>>> Please simplify the above to (untested):
>>> 
>>> #elif defined (__APPLE__)
>>>       /* By default, macOS volumes are case-insensitive, iOS
>>>          volumes are case-sensitive.  */
>>> #if TARGET_OS_MAC    /* macOS, in older SDK.  */
>>>        file_names_case_sensitive_cache = 0;
>>> #elif TARGET_OS_OSX  /* macOS, in recent SDK.  */
>>>        file_names_case_sensitive_cache = 0;
>>> #else                /* assume iOS.  */
>>>        file_names_case_sensitive_cache = 1;
>>> #endif
>>> #else /* Neither Windows nor Apple.  */
>>> 	 file_names_case_sensitive_cache = 1;
>>> #endif
>>> 
>>> which is simpler and more readable and should be equivalent AFAICT.
>>> 
>>> OK with the above change.
>>> 
>>> Arno
>> 
>> Sorry, but that wouldn’t work.
> 
> Then invert the two first tests, that doesn't change the gist of my suggestion to simplify the
> tests.

Apple’s naming is definitely confusing in this area!

In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X variant, 
which covers OSX, IOS, Watch … ; to determine which kind of device, you have to check the 
specific define for that device - OSX corresponds to macOS, i.e. laptops, desktops.

In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as mentioned by Iain) 
TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, desktops as 
above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).

If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC is
set to 1 and TARGET_OS_OSX is set to 1. 

If we were compiling for iOS, using a current iOS SDK as supplied with current Xcode, then 
TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and 
TARGET_OS_IOS would be set to 1.

If TARGET_OS_OSX is defined then
	—  we’re generating code for a recent Apple device, TARGET_OS_MAC could mean 
	—  macOS, iOS, iWatch etc, so we can’t use it.
	if TARGET_OS_OSX is 1 then
		—  we’re generating code for macOS, file names are case-insensitive.
	else
		—  we’re trying to generate code for a device which GCC doesn’t support at 
		—  the moment, e.g. iOS; let’s  assume file names are case-sensitive..
	end if
else
	if TARGET_OS_MAC is 1 then
		—  we’re generating code for macOS, file names are case-insensitve.
	else
		—  let’s assume file names are case-sensitive.
	end if
end if

What we’re doing here is providing a default behaviour; it’s certainly the case that Apple filesystems are by default case-insensitive. If a user has code on case-sensitive file systems (Apple or other, e.g. unix-over-NFS) it’s up to them to use GNAT_FILE_NAME_CASE_SENSITIVE.

>> TargetConditionals.h is created by Apple as part of SDK construction, so the TARGET_* macros are defined directly (#define TARGET_OS_OSX 1),
>> 
>> In a newer macOS SDK, both TARGET_OS_MAC and TARGET_OS_OSX are defined and set to 1, and TARGET_OS_MAC covers OSX (macOS), IOS, TV, WATCH and others.
>> In an older macOS SDK, TARGET_OS_MAC is defined and set to 1, and none of the others are defined at all.
Arnaud Charlet Nov. 17, 2023, 1:36 p.m. UTC | #15 
> Apple’s naming is definitely confusing in this area!
> 
> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X variant, 
> which covers OSX, IOS, Watch … ; to determine which kind of device, you have to check the 
> specific define for that device - OSX corresponds to macOS, i.e. laptops, desktops.
> 
> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as mentioned by Iain) 
> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, desktops as 
> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).
> 
> If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC is
> set to 1 and TARGET_OS_OSX is set to 1. 
> 
> If we were compiling for iOS, using a current iOS SDK as supplied with current Xcode, then 
> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and 
> TARGET_OS_IOS would be set to 1.

OK so then the following is sufficient for our needs:

 #elif defined (__APPLE__)
       /* By default, macOS volumes are case-insensitive, iOS
          volumes are case-sensitive.  */
 #if TARGET_OS_IOS
        file_names_case_sensitive_cache = 1;
 #else
        file_names_case_sensitive_cache = 0;
 #endif
 #else /* Neither Windows nor Apple.  */
    file_names_case_sensitive_cache = 1;
 #endif

We want the default to be 0, and we only care about setting it to 1 on iOS for recent
SDKs, the case of an old SDK and iOS isn't interesting at this stage, so it's fine if we set
the var to 0 in this scenario.

Arno
Arnaud Charlet Nov. 17, 2023, 1:39 p.m. UTC | #16 
> OK so then the following is sufficient for our needs:
> 
>  #elif defined (__APPLE__)
>        /* By default, macOS volumes are case-insensitive, iOS
>           volumes are case-sensitive.  */
>  #if TARGET_OS_IOS
>         file_names_case_sensitive_cache = 1;
>  #else
>         file_names_case_sensitive_cache = 0;
>  #endif
>  #else /* Neither Windows nor Apple.  */
>     file_names_case_sensitive_cache = 1;
>  #endif

Actually you can simplify even further:

  #elif defined (__APPLE__) && !defined(TARGET_OS_IOS)
        /* By default, macOS volumes are case-insensitive, iOS
           volumes are case-sensitive, so fallback below.  */
         file_names_case_sensitive_cache = 0;
  #else /* Neither Windows nor macOS.  */
     file_names_case_sensitive_cache = 1;
  #endif

Arno
Simon Wright Nov. 17, 2023, 1:43 p.m. UTC | #17 
> 
>> Apple’s naming is definitely confusing in this area!
>> 
>> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X variant, 
>> which covers OSX, IOS, Watch … ; to determine which kind of device, you have to check the 
>> specific define for that device - OSX corresponds to macOS, i.e. laptops, desktops.
>> 
>> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as mentioned by Iain) 
>> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, desktops as 
>> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).
>> 
>> If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC is
>> set to 1 and TARGET_OS_OSX is set to 1. 
>> 
>> If we were compiling for iOS, using a current iOS SDK as supplied with current Xcode, then 
>> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and 
>> TARGET_OS_IOS would be set to 1.
> 
> OK so then the following is sufficient for our needs:
> 
> #elif defined (__APPLE__)
>       /* By default, macOS volumes are case-insensitive, iOS
>          volumes are case-sensitive.  */
> #if TARGET_OS_IOS
>        file_names_case_sensitive_cache = 1;
> #else
>        file_names_case_sensitive_cache = 0;
> #endif
> #else /* Neither Windows nor Apple.  */
>    file_names_case_sensitive_cache = 1;
> #endif
> 
> We want the default to be 0, and we only care about setting it to 1 on iOS for recent
> SDKs, the case of an old SDK and iOS isn't interesting at this stage, so it's fine if we set
> the var to 0 in this scenario.

I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on this suggestion.
Iain Sandoe Nov. 21, 2023, 11:22 a.m. UTC | #18 
Hello Simon, Arno,

> On 17 Nov 2023, at 13:43, Simon Wright <simon@pushface.org> wrote:
> 
>> 
>>> Apple’s naming is definitely confusing in this area!
>>> 
>>> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X variant, 
>>> which covers OSX, IOS, Watch … ; to determine which kind of device, you have to check the 
>>> specific define for that device - OSX corresponds to macOS, i.e. laptops, desktops.
>>> 
>>> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as mentioned by Iain) 
>>> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, desktops as 
>>> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).
>>> 
>>> If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC is
>>> set to 1 and TARGET_OS_OSX is set to 1. 
>>> 
>>> If we were compiling for iOS, using a current iOS SDK as supplied with current Xcode, then 
>>> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and 
>>> TARGET_OS_IOS would be set to 1.
>> 
>> OK so then the following is sufficient for our needs:
>> 
>> #elif defined (__APPLE__)
>>      /* By default, macOS volumes are case-insensitive, iOS
>>         volumes are case-sensitive.  */
>> #if TARGET_OS_IOS
>>       file_names_case_sensitive_cache = 1;
>> #else
>>       file_names_case_sensitive_cache = 0;
>> #endif
>> #else /* Neither Windows nor Apple.  */
>>   file_names_case_sensitive_cache = 1;
>> #endif
>> 
>> We want the default to be 0, and we only care about setting it to 1 on iOS for recent
>> SDKs, the case of an old SDK and iOS isn't interesting at this stage, so it's fine if we set
>> the var to 0 in this scenario.
> 
> I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on this suggestion.

* We are far away from having support for watchOS (32b Arm64) so I think that is a bridge
that can be crossed later.

* It seems to me that the proposed solution is better matched to the defaults on macOS/iOS.

* It would be better to have an automatic solution for folks (like me) who do use case-
sensitive file systems on macOS, but we do not have the resources right now to figure
out what is not working on the earlier systems.  I looked briefly, and found that the libcalls
are thin wrappers on a syscall, so that the different behaviours we are seeing on earlier
OS versions reflects the kernel’s handling of the provided path, rather than some improvement
in newer library functions.  That suggests to me that we will need to wrap the call in some more
complex logic to obtain the correct response.

So, I think that (with a test across the range of supported OS versions) the proposed
solution is an incremental improvement and we should take it.

When there’s a final proposed patch, I can add it into my testing across the systems.

Iain
Simon Wright Nov. 21, 2023, 8:25 p.m. UTC | #19 
On 21 Nov 2023, at 11:22, Iain Sandoe <iain@sandoe.co.uk> wrote:
> 
> Hello Simon, Arno,
> 
>> On 17 Nov 2023, at 13:43, Simon Wright <simon@pushface.org> wrote:
>> 
>>> 
>>>> Apple’s naming is definitely confusing in this area!
>>>> 
>>>> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X variant, 
>>>> which covers OSX, IOS, Watch … ; to determine which kind of device, you have to check the 
>>>> specific define for that device - OSX corresponds to macOS, i.e. laptops, desktops.
>>>> 
>>>> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as mentioned by Iain) 
>>>> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, desktops as 
>>>> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).
>>>> 
>>>> If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC is
>>>> set to 1 and TARGET_OS_OSX is set to 1. 
>>>> 
>>>> If we were compiling for iOS, using a current iOS SDK as supplied with current Xcode, then 
>>>> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and 
>>>> TARGET_OS_IOS would be set to 1.
>>> 
>>> OK so then the following is sufficient for our needs:
>>> 
>>> #elif defined (__APPLE__)
>>>     /* By default, macOS volumes are case-insensitive, iOS
>>>        volumes are case-sensitive.  */
>>> #if TARGET_OS_IOS
>>>      file_names_case_sensitive_cache = 1;
>>> #else
>>>      file_names_case_sensitive_cache = 0;
>>> #endif
>>> #else /* Neither Windows nor Apple.  */
>>>  file_names_case_sensitive_cache = 1;
>>> #endif
>>> 
>>> We want the default to be 0, and we only care about setting it to 1 on iOS for recent
>>> SDKs, the case of an old SDK and iOS isn't interesting at this stage, so it's fine if we set
>>> the var to 0 in this scenario.
>> 
>> I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on this suggestion.
> 
> * We are far away from having support for watchOS (32b Arm64) so I think that is a bridge
> that can be crossed later.
> 
> * It seems to me that the proposed solution is better matched to the defaults on macOS/iOS.
> 
> * It would be better to have an automatic solution for folks (like me) who do use case-
> sensitive file systems on macOS, but we do not have the resources right now to figure
> out what is not working on the earlier systems.  I looked briefly, and found that the libcalls
> are thin wrappers on a syscall, so that the different behaviours we are seeing on earlier
> OS versions reflects the kernel’s handling of the provided path, rather than some improvement
> in newer library functions.  That suggests to me that we will need to wrap the call in some more
> complex logic to obtain the correct response.
> 
> So, I think that (with a test across the range of supported OS versions) the proposed
> solution is an incremental improvement and we should take it.
> 
> When there’s a final proposed patch, I can add it into my testing across the systems.
> 
> Iain

Herewith my proposed patch (still in thread, though the subject of the thread isn’t still appropriate):

In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
assumption for __APPLE__ is that file names are case-insensitive
unless __arm__ or __arm64__ are defined, in which case file names are
declared case-sensitive.

The associated comment is
  "By default, we suppose filesystems aren't case sensitive on
  Windows and Darwin (but they are on arm-darwin)."

This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.

The true default position is that macOS file systems are
case-insensitive, iOS file systems are case-sensitive.

Apple provide a header file <TargetConditionals.h> which permits a
compile-time check for the compiler target (e.g. OSX vs IOS); if
TARGET_OS_IOS is defined as 1, this is a build for iOS.

gcc/ada/Changelog:

2023-11-21 Simon Wright <simon@pushface.org <mailto:simon@pushface.org>>

  * gcc/ada/adaint.c (__gnat_get_file_names_case_sensitive):
  Split out the __APPLE__ check and remove the checks for __arm__,
  __arm64__.
  For Apple, file names are by default case-insensitive unless
  TARGET_OS_IOS is set.

Signed-off-by: Simon Wright <simon@pushface.org>
---
 gcc/ada/adaint.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index bb4ed2607e5..0222791ed68 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -84,7 +84,7 @@
 #endif /* VxWorks */
 
 #if defined (__APPLE__)
-#include <unistd.h>
+#include <TargetConditionals.h>
 #endif
 
 #if defined (__hpux__)
@@ -613,11 +613,18 @@ __gnat_get_file_names_case_sensitive (void)
       else
 	{
 	  /* By default, we suppose filesystems aren't case sensitive on
-	     Windows and Darwin (but they are on arm-darwin).  */
-#if defined (WINNT) || defined (__DJGPP__) \
-  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
+	     Windows or DOS.  */
+#if defined (WINNT) || defined (__DJGPP__)
 	  file_names_case_sensitive_cache = 0;
+#elif defined (__APPLE__)
+	  /* By default, macOS volumes are case-insensitive, iOS
+	     volumes are case-sensitive.  */
+#if TARGET_OS_IOS
+	  file_names_case_sensitive_cache = 1;
 #else
+	  file_names_case_sensitive_cache = 0;
+#endif
+#else /* Neither Windows nor Apple.  */
 	  file_names_case_sensitive_cache = 1;
 #endif
 	}
Iain Sandoe Nov. 21, 2023, 11:13 p.m. UTC | #20 
Hi Simon,

Thanks for persevering - I will keep the original patch, pending some chance to
fix the earlier OS issues.

I’ll check this on OS versions with older SDKs that do not have the TARGET_OS_XX
conditionals.

-----

One small nit below,

Iain

> On 21 Nov 2023, at 20:25, Simon Wright <simon@pushface.org> wrote:
> 
> On 21 Nov 2023, at 11:22, Iain Sandoe <iain@sandoe.co.uk> wrote:
>> 
>> Hello Simon, Arno,
>> 
>>> On 17 Nov 2023, at 13:43, Simon Wright <simon@pushface.org> wrote:
>>> 
>>>> 
>>>>> Apple’s naming is definitely confusing in this area!
>>>>> 
>>>>> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X variant, 
>>>>> which covers OSX, IOS, Watch … ; to determine which kind of device, you have to check the 
>>>>> specific define for that device - OSX corresponds to macOS, i.e. laptops, desktops.
>>>>> 
>>>>> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as mentioned by Iain) 
>>>>> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, desktops as 
>>>>> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).
>>>>> 
>>>>> If we are compiling for macOS, using a current macOS SDK, then TARGET_OS_MAC is
>>>>> set to 1 and TARGET_OS_OSX is set to 1. 
>>>>> 
>>>>> If we were compiling for iOS, using a current iOS SDK as supplied with current Xcode, then 
>>>>> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and 
>>>>> TARGET_OS_IOS would be set to 1.
>>>> 
>>>> OK so then the following is sufficient for our needs:
>>>> 
>>>> #elif defined (__APPLE__)
>>>>     /* By default, macOS volumes are case-insensitive, iOS
>>>>        volumes are case-sensitive.  */
>>>> #if TARGET_OS_IOS
>>>>      file_names_case_sensitive_cache = 1;
>>>> #else
>>>>      file_names_case_sensitive_cache = 0;
>>>> #endif
>>>> #else /* Neither Windows nor Apple.  */
>>>>  file_names_case_sensitive_cache = 1;
>>>> #endif
>>>> 
>>>> We want the default to be 0, and we only care about setting it to 1 on iOS for recent
>>>> SDKs, the case of an old SDK and iOS isn't interesting at this stage, so it's fine if we set
>>>> the var to 0 in this scenario.
>>> 
>>> I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on this suggestion.
>> 
>> * We are far away from having support for watchOS (32b Arm64) so I think that is a bridge
>> that can be crossed later.
>> 
>> * It seems to me that the proposed solution is better matched to the defaults on macOS/iOS.
>> 
>> * It would be better to have an automatic solution for folks (like me) who do use case-
>> sensitive file systems on macOS, but we do not have the resources right now to figure
>> out what is not working on the earlier systems.  I looked briefly, and found that the libcalls
>> are thin wrappers on a syscall, so that the different behaviours we are seeing on earlier
>> OS versions reflects the kernel’s handling of the provided path, rather than some improvement
>> in newer library functions.  That suggests to me that we will need to wrap the call in some more
>> complex logic to obtain the correct response.
>> 
>> So, I think that (with a test across the range of supported OS versions) the proposed
>> solution is an incremental improvement and we should take it.
>> 
>> When there’s a final proposed patch, I can add it into my testing across the systems.
>> 
>> Iain
> 
> Herewith my proposed patch (still in thread, though the subject of the thread isn’t still appropriate):
> 
> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
> assumption for __APPLE__ is that file names are case-insensitive
> unless __arm__ or __arm64__ are defined, in which case file names are
> declared case-sensitive.
> 
> The associated comment is
>   "By default, we suppose filesystems aren't case sensitive on
>   Windows and Darwin (but they are on arm-darwin)."
> 
> This means that on aarch64-apple-darwin, file names are treated as
> case-sensitive, which is not the default case.
> 
> The true default position is that macOS file systems are
> case-insensitive, iOS file systems are case-sensitive.
> 
> Apple provide a header file <TargetConditionals.h> which permits a
> compile-time check for the compiler target (e.g. OSX vs IOS); if
> TARGET_OS_IOS is defined as 1, this is a build for iOS.
> 
> gcc/ada/Changelog:
> 
> 2023-11-21 Simon Wright <simon@pushface.org>
> 
>   * gcc/ada/adaint.c (__gnat_get_file_names_case_sensitive):
>   Split out the __APPLE__ check and remove the checks for __arm__,
>   __arm64__.
>   For Apple, file names are by default case-insensitive unless
>   TARGET_OS_IOS is set.
> 
> Signed-off-by: Simon Wright <simon@pushface.org>
> ---
>  gcc/ada/adaint.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
> index bb4ed2607e5..0222791ed68 100644
> --- a/gcc/ada/adaint.c
> +++ b/gcc/ada/adaint.c
> @@ -84,7 +84,7 @@
>  #endif /* VxWorks */
>  
>  #if defined (__APPLE__)
> -#include <unistd.h>

If removing unistd.h is intentional (i.e. you determined that it’s no longer
needed for Darwin), then we should make that a separate patch.

> +#include <TargetConditionals.h>
>  #endif
>  
>  #if defined (__hpux__)
> @@ -613,11 +613,18 @@ __gnat_get_file_names_case_sensitive (void)
>        else
>  	{
>  	  /* By default, we suppose filesystems aren't case sensitive on
> -	     Windows and Darwin (but they are on arm-darwin).  */
> -#if defined (WINNT) || defined (__DJGPP__) \
> -  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
> +	     Windows or DOS.  */
> +#if defined (WINNT) || defined (__DJGPP__)
>  	  file_names_case_sensitive_cache = 0;
> +#elif defined (__APPLE__)
> +	  /* By default, macOS volumes are case-insensitive, iOS
> +	     volumes are case-sensitive.  */
> +#if TARGET_OS_IOS
> +	  file_names_case_sensitive_cache = 1;
>  #else
> +	  file_names_case_sensitive_cache = 0;
> +#endif
> +#else /* Neither Windows nor Apple.  */
>  	  file_names_case_sensitive_cache = 1;
>  #endif
>  	}
> -- 
> 2.39.3 (Apple Git-145)
>
Simon Wright Nov. 22, 2023, 1:54 p.m. UTC | #21 
On 21 Nov 2023, at 23:13, Iain Sandoe <iain@sandoe.co.uk> wrote:

>> #if defined (__APPLE__)
>> -#include <unistd.h>
> 
> If removing unistd.h is intentional (i.e. you determined that it’s no longer
> needed for Darwin), then we should make that a separate patch.

I thought that I’d had to include unistd.h for the first patch in this thread; clearly not!

What I hope will be the final version:

——— 8< .———

In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
assumption for __APPLE__ is that file names are case-insensitive
unless __arm__ or __arm64__ are defined, in which case file names are
declared case-sensitive.

The associated comment is
  "By default, we suppose filesystems aren't case sensitive on
  Windows and Darwin (but they are on arm-darwin)."

This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.

The true default position is that macOS file systems are
case-insensitive, iOS file systems are case-sensitive.

Apple provide a header file <TargetConditionals.h> which permits a
compile-time check for the compiler target (e.g. OSX vs IOS); if
TARGET_OS_IOS is defined as 1, this is a build for iOS.

  * gcc/ada/adaint.c
  (__gnat_get_file_names_case_sensitive): Split out the __APPLE__
  check and remove the checks for __arm__, __arm64__.
  For Apple, file names are by default case-insensitive unless
  TARGET_OS_IOS is set.

Signed-off-by: Simon Wright <simon@pushface.org>
---
 gcc/ada/adaint.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index bb4ed2607e5..2e9c59ae958 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -85,6 +85,7 @@
 
 #if defined (__APPLE__)
 #include <unistd.h>
+#include <TargetConditionals.h>
 #endif
 
 #if defined (__hpux__)
@@ -613,11 +614,18 @@ __gnat_get_file_names_case_sensitive (void)
       else
 	{
 	  /* By default, we suppose filesystems aren't case sensitive on
-	     Windows and Darwin (but they are on arm-darwin).  */
-#if defined (WINNT) || defined (__DJGPP__) \
-  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
+	     Windows or DOS.  */
+#if defined (WINNT) || defined (__DJGPP__)
 	  file_names_case_sensitive_cache = 0;
+#elif defined (__APPLE__)
+	  /* By default, macOS volumes are case-insensitive, iOS
+	     volumes are case-sensitive.  */
+#if TARGET_OS_IOS
+	  file_names_case_sensitive_cache = 1;
 #else
+	  file_names_case_sensitive_cache = 0;
+#endif	  
+#else /* Neither Windows nor Apple.  */
 	  file_names_case_sensitive_cache = 1;
 #endif
 	}
Arnaud Charlet Nov. 22, 2023, 1:55 p.m. UTC | #22 
> >> #if defined (__APPLE__)
> >> -#include <unistd.h>
> > 
> > If removing unistd.h is intentional (i.e. you determined that it’s no longer
> > needed for Darwin), then we should make that a separate patch.
> 
> I thought that I’d had to include unistd.h for the first patch in this thread; clearly not!
> 
> What I hope will be the final version:

OK here.

> ——— 8< .———
> 
> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
> assumption for __APPLE__ is that file names are case-insensitive
> unless __arm__ or __arm64__ are defined, in which case file names are
> declared case-sensitive.
> 
> The associated comment is
>   "By default, we suppose filesystems aren't case sensitive on
>   Windows and Darwin (but they are on arm-darwin)."
> 
> This means that on aarch64-apple-darwin, file names are treated as
> case-sensitive, which is not the default case.
> 
> The true default position is that macOS file systems are
> case-insensitive, iOS file systems are case-sensitive.
> 
> Apple provide a header file <TargetConditionals.h> which permits a
> compile-time check for the compiler target (e.g. OSX vs IOS); if
> TARGET_OS_IOS is defined as 1, this is a build for iOS.
> 
>   * gcc/ada/adaint.c
>   (__gnat_get_file_names_case_sensitive): Split out the __APPLE__
>   check and remove the checks for __arm__, __arm64__.
>   For Apple, file names are by default case-insensitive unless
>   TARGET_OS_IOS is set.
> 
> Signed-off-by: Simon Wright <simon@pushface.org>
Paul Koning Nov. 22, 2023, 2:41 p.m. UTC | #23 
> On Nov 22, 2023, at 8:54 AM, Simon Wright <simon@pushface.org> wrote:
> 
> On 21 Nov 2023, at 23:13, Iain Sandoe <iain@sandoe.co.uk> wrote:
> 
>>> #if defined (__APPLE__)
>>> -#include <unistd.h>
>> 
>> If removing unistd.h is intentional (i.e. you determined that it’s no longer
>> needed for Darwin), then we should make that a separate patch.
> 
> I thought that I’d had to include unistd.h for the first patch in this thread; clearly not!
> 
> What I hope will be the final version:
> 
> ——— 8< .———
> 
> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
> assumption for __APPLE__ is that file names are case-insensitive
> unless __arm__ or __arm64__ are defined, in which case file names are
> declared case-sensitive.
> 
> The associated comment is
>  "By default, we suppose filesystems aren't case sensitive on
>  Windows and Darwin (but they are on arm-darwin)."
> 
> This means that on aarch64-apple-darwin, file names are treated as
> case-sensitive, which is not the default case.
> 
> The true default position is that macOS file systems are
> case-insensitive, iOS file systems are case-sensitive.

Sort of.  The most common choices for Mac OS file system type are indeed case insensitive, but it also allows case sensitive file systems. 

	paul
Iain Sandoe Nov. 22, 2023, 2:48 p.m. UTC | #24 
> On 22 Nov 2023, at 13:55, Arnaud Charlet <charlet@adacore.com> wrote:
> 
>>>> #if defined (__APPLE__)
>>>> -#include <unistd.h>
>>> 
>>> If removing unistd.h is intentional (i.e. you determined that it’s no longer
>>> needed for Darwin), then we should make that a separate patch.
>> 
>> I thought that I’d had to include unistd.h for the first patch in this thread; clearly not!
>> 
>> What I hope will be the final version:
> 
> OK here.

also OK here, thanks
Iain

> 
>> ——— 8< .———
>> 
>> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
>> assumption for __APPLE__ is that file names are case-insensitive
>> unless __arm__ or __arm64__ are defined, in which case file names are
>> declared case-sensitive.
>> 
>> The associated comment is
>>  "By default, we suppose filesystems aren't case sensitive on
>>  Windows and Darwin (but they are on arm-darwin)."
>> 
>> This means that on aarch64-apple-darwin, file names are treated as
>> case-sensitive, which is not the default case.
>> 
>> The true default position is that macOS file systems are
>> case-insensitive, iOS file systems are case-sensitive.
>> 
>> Apple provide a header file <TargetConditionals.h> which permits a
>> compile-time check for the compiler target (e.g. OSX vs IOS); if
>> TARGET_OS_IOS is defined as 1, this is a build for iOS.
>> 
>>  * gcc/ada/adaint.c
>>  (__gnat_get_file_names_case_sensitive): Split out the __APPLE__
>>  check and remove the checks for __arm__, __arm64__.
>>  For Apple, file names are by default case-insensitive unless
>>  TARGET_OS_IOS is set.
>> 
>> Signed-off-by: Simon Wright <simon@pushface.org>
Iain Sandoe Nov. 22, 2023, 3:03 p.m. UTC | #25 
> On 22 Nov 2023, at 14:48, Iain Sandoe <iain@sandoe.co.uk> wrote:
> 
> 
> 
>> On 22 Nov 2023, at 13:55, Arnaud Charlet <charlet@adacore.com> wrote:
>> 
>>>>> #if defined (__APPLE__)
>>>>> -#include <unistd.h>
>>>> 
>>>> If removing unistd.h is intentional (i.e. you determined that it’s no longer
>>>> needed for Darwin), then we should make that a separate patch.
>>> 
>>> I thought that I’d had to include unistd.h for the first patch in this thread; clearly not!
>>> 
>>> What I hope will be the final version:
>> 
>> OK here.
> 
> also OK here, thanks

I think this fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 ?
if you agree then please add that to the commit.
Iain

> Iain
> 
>> 
>>> ——— 8< .———
>>> 
>>> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
>>> assumption for __APPLE__ is that file names are case-insensitive
>>> unless __arm__ or __arm64__ are defined, in which case file names are
>>> declared case-sensitive.
>>> 
>>> The associated comment is
>>> "By default, we suppose filesystems aren't case sensitive on
>>> Windows and Darwin (but they are on arm-darwin)."
>>> 
>>> This means that on aarch64-apple-darwin, file names are treated as
>>> case-sensitive, which is not the default case.
>>> 
>>> The true default position is that macOS file systems are
>>> case-insensitive, iOS file systems are case-sensitive.
>>> 
>>> Apple provide a header file <TargetConditionals.h> which permits a
>>> compile-time check for the compiler target (e.g. OSX vs IOS); if
>>> TARGET_OS_IOS is defined as 1, this is a build for iOS.
>>> 
>>> * gcc/ada/adaint.c
>>> (__gnat_get_file_names_case_sensitive): Split out the __APPLE__
>>> check and remove the checks for __arm__, __arm64__.
>>> For Apple, file names are by default case-insensitive unless
>>> TARGET_OS_IOS is set.
>>> 
>>> Signed-off-by: Simon Wright <simon@pushface.org>
Simon Wright Nov. 22, 2023, 3:13 p.m. UTC | #26 
> On 22 Nov 2023, at 15:03, Iain Sandoe <iain@sandoe.co.uk> wrote:
> 
> 
> 
>> On 22 Nov 2023, at 14:48, Iain Sandoe <iain@sandoe.co.uk> wrote:
>> 
>> 
>> 
>>> On 22 Nov 2023, at 13:55, Arnaud Charlet <charlet@adacore.com> wrote:
>>> 
>>>>>> #if defined (__APPLE__)
>>>>>> -#include <unistd.h>
>>>>> 
>>>>> If removing unistd.h is intentional (i.e. you determined that it’s no longer
>>>>> needed for Darwin), then we should make that a separate patch.
>>>> 
>>>> I thought that I’d had to include unistd.h for the first patch in this thread; clearly not!
>>>> 
>>>> What I hope will be the final version:
>>> 
>>> OK here.
>> 
>> also OK here, thanks
> 
> I think this fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 ?
> if you agree then please add that to the commit.
> Iain

git format-patch does so much, I forgot this, sorry:

gcc/ada/Changelog:

2023-11-22 Simon Wright <simon@pushface.org <mailto:simon@pushface.org>>

PR ada/111909

> 
>> Iain
>> 
>>> 
>>>> ——— 8< .———
>>>> 
>>>> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
>>>> assumption for __APPLE__ is that file names are case-insensitive
>>>> unless __arm__ or __arm64__ are defined, in which case file names are
>>>> declared case-sensitive.
>>>> 
>>>> The associated comment is
>>>> "By default, we suppose filesystems aren't case sensitive on
>>>> Windows and Darwin (but they are on arm-darwin)."
>>>> 
>>>> This means that on aarch64-apple-darwin, file names are treated as
>>>> case-sensitive, which is not the default case.
>>>> 
>>>> The true default position is that macOS file systems are
>>>> case-insensitive, iOS file systems are case-sensitive.
>>>> 
>>>> Apple provide a header file <TargetConditionals.h> which permits a
>>>> compile-time check for the compiler target (e.g. OSX vs IOS); if
>>>> TARGET_OS_IOS is defined as 1, this is a build for iOS.
>>>> 
>>>> * gcc/ada/adaint.c
>>>> (__gnat_get_file_names_case_sensitive): Split out the __APPLE__
>>>> check and remove the checks for __arm__, __arm64__.
>>>> For Apple, file names are by default case-insensitive unless
>>>> TARGET_OS_IOS is set.
>>>> 
>>>> Signed-off-by: Simon Wright <simon@pushface.org>
>
Simon Wright Nov. 28, 2023, 12:16 p.m. UTC | #27 
> On 22 Nov 2023, at 15:13, Simon Wright <simon@pushface.org> wrote:
> 
> 
> 
>> On 22 Nov 2023, at 15:03, Iain Sandoe <iain@sandoe.co.uk> wrote:
>> 
>> 
>> 
>>> On 22 Nov 2023, at 14:48, Iain Sandoe <iain@sandoe.co.uk> wrote:
>>> 
>>> 
>>> 
>>>> On 22 Nov 2023, at 13:55, Arnaud Charlet <charlet@adacore.com> wrote:
>>>> 
>>>>>>> #if defined (__APPLE__)
>>>>>>> -#include <unistd.h>
>>>>>> 
>>>>>> If removing unistd.h is intentional (i.e. you determined that it’s no longer
>>>>>> needed for Darwin), then we should make that a separate patch.
>>>>> 
>>>>> I thought that I’d had to include unistd.h for the first patch in this thread; clearly not!
>>>>> 
>>>>> What I hope will be the final version:
>>>> 
>>>> OK here.
>>> 
>>> also OK here, thanks
>> 
>> I think this fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 ?
>> if you agree then please add that to the commit.
>> Iain
> 
> git format-patch does so much, I forgot this, sorry:
> 
> gcc/ada/Changelog:
> 
> 2023-11-22 Simon Wright <simon@pushface.org <mailto:simon@pushface.org>>
> 
> PR ada/111909

Can we commit this one now, please?

—S

> 
>> 
>>> Iain
>>> 
>>>> 
>>>>> ——— 8< .———
>>>>> 
>>>>> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
>>>>> assumption for __APPLE__ is that file names are case-insensitive
>>>>> unless __arm__ or __arm64__ are defined, in which case file names are
>>>>> declared case-sensitive.
>>>>> 
>>>>> The associated comment is
>>>>> "By default, we suppose filesystems aren't case sensitive on
>>>>> Windows and Darwin (but they are on arm-darwin)."
>>>>> 
>>>>> This means that on aarch64-apple-darwin, file names are treated as
>>>>> case-sensitive, which is not the default case.
>>>>> 
>>>>> The true default position is that macOS file systems are
>>>>> case-insensitive, iOS file systems are case-sensitive.
>>>>> 
>>>>> Apple provide a header file <TargetConditionals.h> which permits a
>>>>> compile-time check for the compiler target (e.g. OSX vs IOS); if
>>>>> TARGET_OS_IOS is defined as 1, this is a build for iOS.
>>>>> 
>>>>> * gcc/ada/adaint.c
>>>>> (__gnat_get_file_names_case_sensitive): Split out the __APPLE__
>>>>> check and remove the checks for __arm__, __arm64__.
>>>>> For Apple, file names are by default case-insensitive unless
>>>>> TARGET_OS_IOS is set.
>>>>> 
>>>>> Signed-off-by: Simon Wright <simon@pushface.org>
>> 
>
Marc Poulhiès Nov. 28, 2023, 1:50 p.m. UTC | #28 
Simon Wright <simon@pushface.org> writes:
>  gcc/ada/Changelog:
>
>  2023-11-22 Simon Wright <simon@pushface.org>
>
>  PR ada/111909
>
> Can we commit this one now, please?

Hello Simon,

Yes we can commit this one, as both Iain and Arnaud ACKed it.

I'll create a proper commit with the change and the fixed commit log and
merge it.

Thanks,
Marc
Marc Poulhiès Nov. 28, 2023, 4:48 p.m. UTC | #29 
Marc Poulhiès <poulhies@adacore.com> writes:

> Simon Wright <simon@pushface.org> writes:
>>  gcc/ada/Changelog:
>>
>>  2023-11-22 Simon Wright <simon@pushface.org>
>>
>>  PR ada/111909
>>
>> Can we commit this one now, please?
>
> Hello Simon,
>
> Yes we can commit this one, as both Iain and Arnaud ACKed it.
>
> I'll create a proper commit with the change and the fixed commit log and
> merge it.

I've merged it as r14-5936-g396db92d3aa741.

Thanks,
Marc
diff mbox series

Patch

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index 2a193efc002..43d166824b0 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -85,6 +85,7 @@ 
 
 #if defined (__APPLE__)
 #include <unistd.h>
+#include <sys/attr.h>
 #endif
 
 #if defined (__hpux__)
@@ -613,11 +614,48 @@  __gnat_get_file_names_case_sensitive (void)
       else
 	{
 	  /* By default, we suppose filesystems aren't case sensitive on
-	     Windows and Darwin (but they are on arm-darwin).  */
-#if defined (WINNT) || defined (__DJGPP__) \
-  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
+	     Windows or DOS.  */
+#if defined (WINNT) || defined (__DJGPP__)
 	  file_names_case_sensitive_cache = 0;
-#else
+#elif defined (__APPLE__)
+	  /* Determine whether the current volume is case-sensitive.  */
+	  {
+	    /* Formulate a query for the volume capabilities.  */
+	    struct attrlist attrList
+	      = {ATTR_BIT_MAP_COUNT,
+		 0,				      /* reserved.  */
+		 0,				      /* commonattr.  */
+		 ATTR_VOL_INFO | ATTR_VOL_CAPABILITIES, /* volattr.  */
+		 0,				      /* dirattr.  */
+		 0,				      /* fileattr.  */
+		 0				      /* forkattr.  */
+		};
+
+	    /* A buffer to contain just the volume capabilities.  */
+	    struct returnBuf {
+	      u_int32_t length;
+	      vol_capabilities_attr_t caps;
+	    } __attribute__ ((aligned (4), packed)) retBuf;
+
+	    /* Default to case-insensitive.  */
+	    file_names_case_sensitive_cache = 0;
+
+	    /* Query the current working directory.  */
+	    if (getattrlist (".",
+			     &attrList,
+			     &retBuf,
+			     sizeof (retBuf),
+			     0) == 0)
+	      /* The call succeeded.  */
+	      if ((retBuf.caps.valid[VOL_CAPABILITIES_FORMAT]
+		   & VOL_CAP_FMT_CASE_SENSITIVE))
+		/* The volume could be case-sensitive.  */
+		if (retBuf.caps.capabilities[VOL_CAPABILITIES_FORMAT]
+		    & VOL_CAP_FMT_CASE_SENSITIVE)
+		  /* The volume is case-sensitive.  */
+		  file_names_case_sensitive_cache = 1;
+	  }
+#else /* Neither Windows nor Apple.  */
 	  file_names_case_sensitive_cache = 1;
 #endif
 	}