[MacPorts] #67754: legacysupport implementation of fdopendir closes fd, and this breaks some software

[MacPorts]

#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:
Resolution:                 |   Keywords:
      Port:  legacysupport  |
----------------------------+--------------------
Description changed by kencu:

Old description:

> 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
> seekdir(), the behavior is undefined. Upon calling closedir() the file
> descriptor shall be closed."
>
> So fdopendir may need to be changed to close the fd later, when closedir
> is called.

New description:

 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 such 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
 seekdir(), the behavior is undefined. Upon calling closedir() the file
 descriptor shall be closed."

 So fdopendir may need to be changed to close the fd later, when closedir
 is called.

--

-- 
Ticket URL: <https://trac.macports.org/ticket/67754#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS