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
