Notes |
(0004667)
shware_systems (reporter)
2019-11-27 06:11
|
Since the scandir interface returns its result array via malloc's, size_t is a more appropriate type than off_t to ensure the result range is adequate. Similar applies with telldir() and seekdir() when the implementation uses record counts rather than a byte oriented file position to track entries.
In looking over the interface descriptions there is an issue with scandir(), in that it is not explicit for any error, especially that occurs after sel returns a match, that it is the responsibility of the interface to free any successfully allocated result strings and the memory for the array of string pointers, before returning -1 to indicate the traverse could not be completed. In low free memory conditions ENOMEM due to trying to allocate one of these is likely to occur. |
|
(0004668)
joerg (reporter)
2019-11-27 10:13
|
scandir() is an interface from the past that had more issues in the past already.
Original implementations have e.g. been written with the directory entry size of UFS in mind and failed with filesystems that do not follow these "rules".
How about scandiro() like ftello()? |
|
(0004705)
Don Cragun (manager)
2020-01-06 16:44
|
This issue was discussed during our 2020-01-06 conference call.
The Description provides a series of interesting facts, but we have no existing practice to standardize. Furthermore, we do not expect that people will actually place more files in a directory than can fit into an int. And, if we ever do get to tha point, we expect that the size of an int will also have increased by then.
Since the Desired Action is "None...", we are accepting this bug as marked rather than rejecting it.
Note to the editor: No changes are required in the standard. |
|