NAME_MAX on MingW

NAME_MAX on MingW

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

NAME_MAX is defined in limits.h.

And indeed it is there on Mingw, but guarded by the Windows-specific
non-standard macro _POSIX_.

I found this suggestion that Windows system headers have not used _POSIX_
since MSVC 2013:
https://sourceforge.net/p/mingw-w64/mailman/message/33014416/

However, the macro is still used in the fixed system header with GCC 10 in
my bang-up-to-date Mingw installation.

I can't see this macro referenced anywhere in gnulib's history.

So my question is: is there something gnulib can/should do here?

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1861 bytes --]

Re: NAME_MAX on MingW

[Bruno Haible]

Hi Reuben,

> NAME_MAX is defined in limits.h.

No. POSIX [1] specifies that it may be omitted from <limits.h>, and
that pathconf (_PC_NAME_MAX) is the right way to access the maximum
length of a file name component. [2]

> So my question is: is there something gnulib can/should do here?

I don't see anything Gnulib should do here.

Bruno

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/pathconf.html

Re: NAME_MAX on MingW

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

On Mon, 8 Mar 2021 at 00:14, Bruno Haible <bruno@clisp.org> wrote:

> Hi Reuben,
>
> > NAME_MAX is defined in limits.h.
>
> No. POSIX [1] specifies that it may be omitted from <limits.h>, and
> that pathconf (_PC_NAME_MAX) is the right way to access the maximum
> length of a file name component. [2]
>

Ah, thanks for setting me straight!

[-- Attachment #2: Type: text/html, Size: 859 bytes --]

Re: NAME_MAX on MingW

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

On Mon, 8 Mar 2021 at 00:14, Bruno Haible <bruno@clisp.org> wrote:

>
> I don't see anything Gnulib should do here.
>

Having looked into this, it seems that the same issues apply to PATH_MAX,
yet gnulib has a pathmax module to define PATH_MAX. What's different in
that case?

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1032 bytes --]

Re: NAME_MAX on MingW

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

On Mon, 8 Mar 2021 at 00:16, Reuben Thomas <rrt@sc3d.org> wrote:

> On Mon, 8 Mar 2021 at 00:14, Bruno Haible <bruno@clisp.org> wrote:
>
>> Hi Reuben,
>>
>> > NAME_MAX is defined in limits.h.
>>
>> No. POSIX [1] specifies that it may be omitted from <limits.h>, and
>> that pathconf (_PC_NAME_MAX) is the right way to access the maximum
>> length of a file name component. [2]
>>
>
> Ah, thanks for setting me straight!
>

Unfortunately, this doesn't help, because pathconf is not present on mingw.
So the best I can do is #define _POSIX_ to get the value of NAME_MAX that
it has.

So given that the pathconf constants are available like this on mingw,
perhaps there is something gnulib can do? I'm not sure what is best,
whether simply to allow those constants to be found by defining _POSIX_, or
to implement pathconf with them.

In any case: the information does already exist in some form, and there's
no way to get at it portably with gnulib, that I can see.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2377 bytes --]

Re: NAME_MAX on MingW

[Bruno Haible]

Reuben Thomas wrote:
> Having looked into this, it seems that the same issues apply to PATH_MAX,
> yet gnulib has a pathmax module to define PATH_MAX. What's different in
> that case?

Most systems have a PATH_MAX, only the Hurd doesn't.
Whereas only few systems have a NAME_MAX (musl libc, Cygwin, Haiku).

Therefore more existing code uses PATH_MAX.

Bruno

Re: NAME_MAX on MingW

[Bruno Haible]

Hi Reuben,

> Unfortunately, this doesn't help, because pathconf is not present on mingw.

Then use some fallback, e.g. 256 or PATH_MAX.

> So the best I can do is #define _POSIX_ to get the value of NAME_MAX that
> it has.

Speaking for Gnulib, we cannot support _POSIX_ on mingw. This macro modifies
the behaviour of the header files in 23 places. We already have enough work
with the various header files origins and modes (from Microsoft, with clang,
from old mingw, from mingw64, UNICODE or not,__USE_MINGW_ANSI_STDIO,
_USE_32BIT_TIME_T). We do not need yet another variant, _POSIX_.

Bruno

Re: NAME_MAX on MingW

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On Mon, 8 Mar 2021 at 10:06, Bruno Haible <bruno@clisp.org> wrote:

> Hi Reuben,
>
> > Unfortunately, this doesn't help, because pathconf is not present on
> mingw.
>
> Then use some fallback, e.g. 256 or PATH_MAX.
>
> > So the best I can do is #define _POSIX_ to get the value of NAME_MAX that
> > it has.
>
> Speaking for Gnulib, we cannot support _POSIX_ on mingw. This macro
> modifies
> the behaviour of the header files in 23 places. We already have enough work
> with the various header files origins and modes (from Microsoft, with
> clang,
> from old mingw, from mingw64, UNICODE or not,__USE_MINGW_ANSI_STDIO,
> _USE_32BIT_TIME_T). We do not need yet another variant, _POSIX_.
>

OK, thanks! Maybe Mingw will fix this one day…

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1346 bytes --]