View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000831 | 1003.1(2013)/Issue7+TC1 | System Interfaces | public | 2014-03-29 23:16 | 2014-04-03 15:35 |
| Reporter | sstewartgallus | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Duplicate | ||
| Name | Steven Stewart-Gallus | ||||
| Organization | |||||
| User Reference | |||||
| Section | readdir_r | ||||
| Page Number | |||||
| Line Number | |||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000831: How to allocate memory for readdir_r is unclear. | ||||
| Description | The Linux man-pages project suggests that one allocates memory for the entry structure passed to readdir_r as follows: len = offsetof(struct dirent, d_name) + pathconf(dirpath, _PC_NAME_MAX) + 1 entryp = malloc(len); This seems wrong, the Linux man-pages say that _PC_NAME_MAX returns the maximum length of a filename that a process is allowed to create and not the maximum length of a filename allowed in a directory. The POSIX standard does not give a clear explanation of how to allocate memory for the directory entries. I hypothesize that what is intended is that one allocates space for an entry with a name containing at least {NAME_MAX}+1 elements and that one reallocates the entry length (perhaps doubling or tripling it) when an EOVERFLOW error occurs. POSIX seems to suggest this interpretation in it's explanation for fpathconf, and pathconf: Note that implementations are allowed to accept pathnames longer than {PATH_MAX} bytes long, but are not allowed to return pathnames longer than this unless the user specifies a larger buffer using a function that provides a buffer size argument. This suggest that one would not get an entry from readdir_r if the entry was too small but only possibly an EOVERFLOW error. Given that there are misunderstandings of how to use the readdir_r function out in the wild and that POSIX does not give a clear explanation I would like to request an example in the standard clarifying how one should use the readdir_r function. | ||||
| Desired Action | Please add a clarifying example to the documentation for readdir_r. | ||||
| Tags | No tags attached. | ||||
| duplicate of | 0000696 | Closed | either NAME_MAX shouldn't be optional, or readdir_r() needs clarification |
|
|
We are proposing marking readdir_r as obsolete in the next version of the standard, because its interface is inherently unusable by design. See more details in 0000696 |
|
|
Thank you, my apologies for opening a duplicate issue. I will eagerly follow the status in http://austingroupbugs.net/view.php?id=696 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-03-29 23:16 | sstewartgallus | New Issue | |
| 2014-03-29 23:16 | sstewartgallus | Name | => Steven Stewart-Gallus |
| 2014-03-29 23:16 | sstewartgallus | Section | => readdir_r |
| 2014-03-29 23:32 | eblake | Relationship added | duplicate of 0000696 |
| 2014-03-29 23:33 | eblake | Note Added: 0002208 | |
| 2014-03-29 23:56 | sstewartgallus | Note Added: 0002209 | |
| 2014-03-30 00:16 | sstewartgallus | Note Edited: 0002209 | |
| 2014-03-30 00:17 | sstewartgallus | Note Edited: 0002209 | |
| 2014-03-30 00:17 | sstewartgallus | Note Edited: 0002209 | |
| 2014-04-03 15:35 | nick | Interp Status | => --- |
| 2014-04-03 15:35 | nick | Status | New => Closed |
| 2014-04-03 15:35 | nick | Resolution | Open => Duplicate |
