View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001620 | Issue 8 drafts | Base Definitions and Headers | public | 2022-11-22 03:55 | 2022-11-28 16:30 |
| Reporter | calestyo | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Closed | Resolution | Rejected | ||
| Product Version | Draft 2.1 | ||||
| Name | Christoph Anton Mitterer | ||||
| Organization | |||||
| User Reference | |||||
| Section | 3.243 Pathname, 4.14 Pathname Resolution | ||||
| Page Number | 63 resp. 93 | ||||
| Line Number | 1967 ff. resp. 2830 ff. | ||||
| Final Accepted Text | |||||
| Summary | 0001620: is the empty string a valid pathname? | ||||
| Description | Hey. It seems the current wordings of: 3.243 Pathname and via that also of: 3.297 Relative Pathname do not exclude the empty string to be considered a pathname. 3.243 says: > In the context of POSIX.1-202x, a pathname may > be limited to {PATH_MAX} bytes, including the > terminating null byte. So there is no minimum size. > It has optional beginning <slash> characters, > followed by zero or more filenames separated by > <slash> characters. A pathname can optionally > contain one or more trailing <slash> characters. Since the <slash> characters in the beginning are optional, those may be followed by possibly zero filenames and there may be no trailing <slash> characters, the empty string seems to be a valid pathname. And the same via 3.297 Relative Pathname, which says: > A pathname not beginning with a <slash> character. So the empty string would also be a relative pathname. 4.14 Pathname Resolution says: > A null pathname shall not be successfully resolved. One could not start nitpicking whether this means that just the resolution o such pathname should fail.. or whether such pathnames are disallowed per se. ;-) | ||||
| Desired Action | ... but wouldn't it make sense to clarify in 3.243 Pathname and 3.297 Relative Pathname that empty pathnames are not valid (if so)? Thanks, Chris. | ||||
| Tags | No tags attached. | ||||
|
|
s/One could not start nitpicking/One could now start nitpicking/ |
|
|
If an empty/null string was not a valid pathname, 4.14 Pathname Resolution would not be able to use the phrase "null pathname" as such a thing would not exist. Also, if it was not a valid pathname you would expect interfaces that take a pathname to return an EINVAL error when the argument is empty, but they don't - they return an ENOENT error, indicating that it is a valid pathname that does not resolve. The definition of pathname in XBD chapter 3 includes a cross-reference to 4.14 Pathname Resolution; I don't see the need to repeat any detail from that section in the definition. This bug should be rejected. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-11-22 03:55 | calestyo | New Issue | |
| 2022-11-22 03:55 | calestyo | Name | => Christoph Anton Mitterer |
| 2022-11-22 03:55 | calestyo | Section | => 3.243 Pathname, 4.14 Pathname Resolution |
| 2022-11-22 03:55 | calestyo | Page Number | => 63 resp. 93 |
| 2022-11-22 03:55 | calestyo | Line Number | => 1967 ff. resp. 2830 ff. |
| 2022-11-22 04:00 | calestyo | Note Added: 0006082 | |
| 2022-11-22 08:58 | geoffclare | Note Added: 0006083 | |
| 2022-11-28 16:30 | geoffclare | Status | New => Closed |
| 2022-11-28 16:30 | geoffclare | Resolution | Open => Rejected |
