[MacPorts] #67754: legacysupport implementation of fdopendir closes fd, and this breaks some software
MacPorts
noreply at macports.org
Sun Jul 16 20:00:48 UTC 2023
#67754: legacysupport implementation of fdopendir closes fd, and this breaks some
software
--------------------+---------------------------
Reporter: kencu | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Keywords: | Port: legacysupport
--------------------+---------------------------
After fdopendir was added to legacysupport, it was noted that there was a
leak in the function.
So an interested user added a new bit of code to our fdopendir function to
close the fd.
https://github.com/macports/macports-legacy-
support/commit/3c9d3c2fc4efb9d1e58e9fb9d44899463391a276
This seemed to meet the implementation spec at the time:
""After a successful call to fdopendir(), fd is used internally by the
implementation, and should not otherwise be used by the application."
but it turns out that some software still uses "fd" after the call to
fdopendir. So this software is broken by the fdopendir implementation in
macports.
see:
https://github.com/macports/macports-ports/pull/19047
This does seem to be in the POSIX spec:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fdopendir.html
"Upon successful return from fdopendir(), the file descriptor is under the
control of the system, and if any attempt is made to close the file
descriptor, or to modify the state of the associated description, other
than by means of closedir(), readdir(), readdir_r(), rewinddir(), or [XSI]
[Option Start] seekdir(), [Option End] the behavior is undefined. Upon
calling closedir() the file descriptor shall be closed."
So fdopendir and related calls may need to be changed somehow to close the
fd later on.
--
Ticket URL: <https://trac.macports.org/ticket/67754>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list