That is the maximum length of a directory or file name. Add 1 and multiply by maximum directory depth (if any).
On Thu, Dec 3, 2020 at 4:56 PM Charles Mills <charl...@mcn.org> wrote: > > I see > > #define FILENAME_MAX 1024 > > in stdio.h V2R4 > > Where does that fit into this conundrum? > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Charles Mills > Sent: Thursday, December 3, 2020 9:41 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: C macro for maximum path length? > > Thanks @Gord, yes, I saw pathconf(). > > I am starting to "get" the problem. > > > I suspect there's a buffer overrun hazard associated with a statically > > compiled > > PATH_MAX. > > Never mind the exact lack of a macro and never mind z/OS. Let's say one were > to build a hypothetical program with a buffer of hard-coded length 'n', the > maximum path length for the environment. What is to stop a future release of > the environment from allowing path names with a length greater than 'n'? Now > all of a sudden the program is in danger of buffer overrun. > > The real question is not "how long can a path be [today]?" but rather "how > long might a path be at any future point when this compilation is running?" > and that is kind of an unanswerable question, barring some sort of vendor SOD > like "it is our intention never to increase maximum path length beyond 4095." > It is a problem somewhat analogous to the problem of old programs and an EXEC > PARM longer than 100 bytes. > > Yes, it is a question that pathconf() answers, although it seems to me that > doing it filename by filename is overly complicated: why not just a single, > static for a given environment, "maximum path length of any possible file on > this system"? (Answer: because they didn't ask me. @Gil's link below provides > a better answer.) > > I am simply going to recode my routine to finesse the problem. It currently > has a "work buffer" of length PATH_MAX. It is kind of a lazy programmer's > approach. I am going to re-code it to malloc (actually, to "new" -- it's C++) > a buffer of the necessary length for every path that it processes. I need a > dedicated area for each name eventually anyway (and yes, that I delete > eventually). That's why I say the "work buffer" was kind of a lazy programmer > approach. > > Thanks all for your patience and explanations. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Thursday, December 3, 2020 9:08 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: C macro for maximum path length? > > On Thu, 3 Dec 2020 11:49:05 -0500, Gord Tomlin wrote: > > >On 2020-12-03 10:12 AM, Charles Mills wrote: > >> I believe you, but why then is the macro undefined? Why is the definition > >> now commented out? > >> > I suspect there's a buffer overrun hazard associated with a statically > compiled > PATH_MAX. Interesting, apparently well-researched link: > https://eklitzke.org/path-max-is-tricky > > >> >From <limits.h> (actually CEE.SCEEH.H(LIMITS)) on z/OS V2R4: > >> /* > >> * POSIX.1 1990 Section 2.8.5 Statement 1065 - > >> * these macros "shall be omitted on specific > >> * implementations where the corresonding value is > >> * >= the stated minimum, but where the value > >> * can vary depending on the file to which it is > >> * applied." > >> * ... > >> * #define LINK_MAX > >> * #define MAX_CANON > >> * #define MAX_INPUT > >> * #define NAME_MAX > >> * #define PATH_MAX > >> * #define PIPE_BUF > >> */ > > > >"an application may use the/fpathconf/() > ><https://pubs.opengroup.org/onlinepubs/009696699/functions/fpathconf.html>,/pathconf/() > > <https://pubs.opengroup.org/onlinepubs/009696699/functions/pathconf.html>, > >and/sysconf/() > ><https://pubs.opengroup.org/onlinepubs/009696699/functions/sysconf.html> > >functions to > >determine the actual value of a limit at runtime." > > > >(<https://pubs.opengroup.org/onlinepubs/009696699/basedefs/limits.h.html>) > > > OpenGroup/Single UNIX requires an "allocating" form of realpath(); > z/OS XL C/C++ fails to provide one. > > More: > What is the OP doing with this? > > Even more: > https://eklitzke.org/path-max-is-tricky > > Rexx ADDRESS SYSCALL realpath > returns strings which appear correct but seem to exceed the > PATH_MAX computed by pathconf(). When I expressed astonishment > about that on MVS-OE, WJS replied: > http://vm.marist.edu/htbin/wlvtype?MVS-OE.61764 > I suspect C passes a buffer of PATH_MAX+1. The REXX support tends to use a > local 4K scratch buffer for system call output areas when it can, and does > in this case. > I.e. just define it as 4K and hope for the best. > > I'll try this on Linux: > ( set -x; while true; do mkdir wombat; cd wombat; pwd; done ) > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
