steve@unidata.ucar.edu (Steve Emmerson) (04/06/91)
Submitted-by: steve@unidata.ucar.edu (Steve Emmerson) Hi, Would someone who knows please tell me the relationship between the Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX. In particular, should they be the same, or should FILENAME_MAX correspond instead to _POSIX_NAME_MAX. I ask because HP-UX has FILENAME_MAX set to 14 and we think this is wrong. Thanks in advance, Steve Emmerson steve@unidata.ucar.edu ...!ncar!unidata!steve Volume-Number: Volume 23, Number 24
willcox@urbana.mcd.mot.com (David A Willcox) (04/08/91)
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox) >Would someone who knows please tell me the relationship between the >Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX. Since FILENAME_MAX is the longest possible filename string that can be passed to fopen() and the like, it should be a value no smaller than the largest possible value for PATH_MAX on your system. It mustn't ever be smaller than _POSIX_PATH_MAX, and would only be that small on an implementation that only supported the minimum value for PATH_MAX required by POSIX. To quote from the C standard, FILENAME_MAX: ... expands to an integral constant expression that is the size needed for an array of char large enough to hold the longest file name string that the implementation guarantees can be opened. [There's a footnote saying that this doesn't mean that just any string this long is a valid file name.] Since the C standard does not have any concept of directories, "file name" in this context clearly corresponds to a POSIX path, not an individual file name. (Standard disclaimer stuff. Motorola and POSIX disavow all knowledge of my actions.) David A. Willcox "Just say 'NO' to universal drug testing" Motorola MCD - Urbana UUCP: ...!uiucuxc!udc!willcox 1101 E. University Ave. INET: willcox@urbana.mcd.mot.com Urbana, IL 61801 FONE: 217-384-8534 Volume-Number: Volume 23, Number 25
karish@mindcraft.com (Chuck Karish) (04/10/91)
Submitted-by: karish@mindcraft.com (Chuck Karish) In article <127638@uunet.UU.NET> steve@unidata.ucar.edu (Steve Emmerson) writes: >Would someone who knows please tell me the relationship between the >Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX. > >In particular, should they be the same, or should FILENAME_MAX >correspond instead to _POSIX_NAME_MAX. _POSIX_PATH_MAX is more appropriate. Standard C has no notion of a path prefix. Clause 4.9.1 of both the Standard and its rationale tells us that a buffer of FILENAME_MAX characters should hold the entire file name (what POSIX.1 would term the 'path'). Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000 Volume-Number: Volume 23, Number 26
decot@hpisod2.cup.hp.com (Dave Decot) (04/11/91)
Submitted-by: decot@hpisod2.cup.hp.com (Dave Decot) > To quote from the C standard, FILENAME_MAX: > > ... expands to an integral constant expression that is the size needed > for an array of char large enough to hold the longest file name > string that the implementation guarantees can be opened. [There's > a footnote saying that this doesn't mean that just any string this > long is a valid file name.] They can footnote all they want; the text requires me to set FILENAME_MAX to the size of the longest filename I *guarantee* can be opened. The length of that filename is 8, because I *guarantee* that the file "/dev/tty" can be opened. Anything else, depends on what's on the system. I wish the ANSI committee would stop insisting that the wording is entirely perfect in all respects and that therefore any unintended reading of the wording is stupidity on the part of the reader. Dave Volume-Number: Volume 23, Number 27
willcox@urbana.mcd.mot.com (David A Willcox) (04/11/91)
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox) >>Would someone who knows please tell me the relationship between the >>Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX. >_POSIX_PATH_MAX is more appropriate. Standard C has no notion of a >path prefix. Clause 4.9.1 of both the Standard and its rationale >tells us that a buffer of FILENAME_MAX characters should hold >the entire file name (what POSIX.1 would term the 'path'). _POSIX_PATH_MAX is probably not the correct value, unless your implementation never supports anything larger than the minimum required by POSIX. PATH_MAX would be better, if it's defined on your implementation (implying that you don't need to call pathconf() to get a path-specific value). If PATH_MAX isn't defined, then FILENAME_MAX must be no smaller than the largest value you can get from pathconf(_PC_PATH_MAX,...). David A. Willcox "Just say 'NO' to universal drug testing" [ Standards are such lovely things... -mod ] Volume-Number: Volume 23, Number 28
goudreau@dg-rtp.dg.com (Bob Goudreau) (04/11/91)
Submitted-by: goudreau@dg-rtp.dg.com (Bob Goudreau) In article <128358@uunet.UU.NET>, decot@hpisod2.cup.hp.com (Dave Decot) writes: > > > To quote from the C standard, FILENAME_MAX: > > > > ... expands to an integral constant expression that is the size needed > > for an array of char large enough to hold the longest file name > > string that the implementation guarantees can be opened. [There's > > a footnote saying that this doesn't mean that just any string this > > long is a valid file name.] > > They can footnote all they want; the text requires me to set FILENAME_MAX > to the size of the longest filename I *guarantee* can be opened. I believe the point about the footnote was that string-length is not the *only* criterion in determining if the filename is valid. The system may disallow various characters from filenames, for example. The relevant footnote text is: Of course, file name string contents are subject to other system-specific constraints; therefore, _all_ possible strings of length FILENAME_MAX cannot be expected to be opened sucessfully. ---------------------------------------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation goudreau@dg-rtp.dg.com 62 Alexander Drive ...!mcnc!rti!xyzzy!goudreau Research Triangle Park, NC 27709, USA Volume-Number: Volume 23, Number 29
karish@mindcraft.com (Chuck Karish) (04/13/91)
Submitted-by: karish@mindcraft.com (Chuck Karish) In article <128358@uunet.UU.NET> decot@hpisod2.cup.hp.com (Dave Decot) writes: >[ X3J11 ] can footnote all they want; the text requires me to set FILENAME_MAX >to the size of the longest filename I *guarantee* can be opened. > >The length of that filename is 8, because I *guarantee* that the file >"/dev/tty" can be opened. Anything else, depends on what's on the system. I hadn't noticed that they prohibited the use of the O_CREAT flag in your call to open(). What's the fuss about? The C committee was trying to make it possible to write portable programs, not to constrain what must be present on your system. They were doomed to failure in an environment as complex as POSIX. That's why we have pathconf(). It's still reasonable to let the programmer know whether it's necessary to provide 13 characters or 256 or 1024 to hold a filename. Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000 Volume-Number: Volume 23, Number 33
lewine@cheshirecat.webo.dg.com (Donald Lewine) (04/18/91)
Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine) In article <129356@uunet.UU.NET>, karish@mindcraft.com (Chuck Karish) writes: |> The C committee was trying to make it possible to write portable |> programs, not to constrain what must be present on your system. |> They were doomed to failure in an environment as complex as POSIX. |> That's why we have pathconf(). It's still reasonable to let the |> programmer know whether it's necessary to provide 13 characters |> or 256 or 1024 to hold a filename. |> Yes, it is very reasonable to let the programmer know whether it is necessary to 13 or 1024 characters to hold a pathname. Alas, POSIX does not do it! The symbols PATH_MAX and the values returned by pathconf() are pretty useless. The standard says that PATH_MAX is "Maximum number of bytes in a pathname" (Table 2-5). That statement is misleading, if not a complete lie. PATH_MAX is the longest pathname an application is guaranteed to be able to create. Most applications do not care about the longest pathname the are guaranteed to be able to create. They need to know the longest pathname that will be encoundered. In other words, how much storage should be allocated for the user's response to a "File: " prompt. Or, how large should the buffer be for getcwd(). Or, what is the longest path a file tree walk will encounter. _POSIX_PATH_MAX, PATH_MAX and pathconf() do not give any insight into those questions. Since most systems define PATH_MAX to be a large number, applications that use PATH_MAX to allocate buffers for getcwd() or user-supplied pathnames tend to work. The standard does not guarantee that they will work. In fact, even in their intended role, these symbols are not much use. I can always try to open() a file and see what error code comes back. In short, the only practical value is _POSIX_PATH_MAX is to force implementers to allow 256 character pathnames on all systems. It has no value to application programmers. -------------------------------------------------------------------- Donald A. Lewine (508) 870-9008 Voice Data General Corporation (508) 366-0750 FAX 4400 Computer Drive. MS D112A Westboro, MA 01580 U.S.A. uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com Volume-Number: Volume 23, Number 34
henry@zoo.toronto.edu (Henry Spencer) (04/21/91)
Submitted-by: henry@zoo.toronto.edu (Henry Spencer) In article <129469@uunet.UU.NET> lewine@dg.uucp writes: >... Most applications do not care >about the longest pathname the are guaranteed to be able to create. >They need to know the longest pathname that will be encoundered. >In other words, how much storage should be allocated for the user's >response to a "File: " prompt. Or, how large should the buffer be >for getcwd(). Or, what is the longest path a file tree walk will >encounter. _POSIX_PATH_MAX, PATH_MAX and pathconf() do not give >any insight into those questions. Maybe because there is no answer to these questions? There is *no limit* to these lengths in some Unix systems, notably V6 and V7 of hallowed memory. Programmers who hope to allocate fixed-sized arrays for these purposes are simply demonstrating their laziness and ignorance. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry Volume-Number: Volume 23, Number 36