> -----Original Message-----
> From: Rainer Orth <r...@cebitec.uni-bielefeld.de>
> Sent: Friday, April 11, 2025 05:17
> To: gcc-patches@gcc.gnu.org
> Cc: Robert Dubner <rdub...@symas.com>; James K. Lowden
> <jklow...@cobolworx.com>
> Subject: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]
>
> All users of symbols.h fail to compile on Solaris:
>
> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error:
> ‘NAME_MAX’ was not declared in this scope
> 1365 | char name[NAME_MAX];
> | ^~~~~~~~
>
> NAME_MAX being undefined is allowed by POSIX.1, actually: it's listed
> for <limits.h> under "Pathname Variable Values":
>
> A definition of one of the symbolic constants in the following list
> shall be omitted from the <limits.h> header on specific implementations
> where the corresponding value is equal to or greater than the stated
> minimum, but where the value can vary depending on the file to which it
> is applied. The actual value supported for a specific pathname shall be
> provided by the pathconf() function.
>
> As a hack, this patch provides a fallback definition to allow the build
> to finish.
>
> Bootstrapped without regressions on amd64-pc-solaris2.11,
> sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
>
> Ok for trunk?
I agree that this is an expedient way of getting things to compile on
systems that lack NAME_MAX. I will be following through to see what are the
implications of eliminating it completely.
It is OK for trunk.
>
> Rainer
>
> --
> --------------------------------------------------------------------------
> ---
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2025-04-08 Rainer Orth <r...@cebitec.uni-bielefeld.de>
>
> gcc/cobol:
> PR cobol/119217
> * symbols.h (NAME_MAX): Define fallback.
