Created attachment 207447 [details]
Use closefrom() to avoid call close() for all possible descriptors
This change is best suited to submitting upstream first. Please create an issue or PR upstream, and add the issue/PR URL reference to the patch so we can track the patch locally until a future release comes out with the change
Comment on attachment 207447 [details]
Upstream PR: https://gitlab.freedesktop.org/dbus/dbus/merge_requests/124
A commit in branch main references this bug:
Author: Adriaan de Groot <adridg@FreeBSD.org>
AuthorDate: 2021-05-13 22:57:15 +0000
Commit: Adriaan de Groot <adridg@FreeBSD.org>
CommitDate: 2021-05-14 19:08:18 +0000
devel/dbus: use closefrom()
Don't do 1021 calls to close() when a single closefrom() will do.
This patch has been submitted upstream (by the reporter) but
is languishing there; there's a big difference between upstream's
development branch and the released stable version. I've taken
the initial patch from FreeBSD bugzilla, lightly mutated it with
Reported by: firstname.lastname@example.org
devel/dbus/Makefile | 2 +-
.../files/patch-cmake_ConfigureChecks.cmake (new) | 10 ++++++++++
devel/dbus/files/patch-cmake_config.h.cmake (new) | 12 ++++++++++++
.../dbus/files/patch-dbus_dbus-sysdeps-unix.c (new) | 21 +++++++++++++++++++++
4 files changed, 44 insertions(+), 1 deletion(-)
(In reply to commit-hook from comment #5)
+#cmakedefine HAVE_CLOSEFROM 1
Why __FreeBSD__ and not HAVE_CLOSEFROM?
The buildsystem is (still) autotools and the patch that is in the DBus MR doesn't apply cleanly to the older (stable) version we ship; I could adjust it to patching the configure.ac from the release, but that means then running all the autotools as part of the build. And for what? There's no version of ports that we care about, that would not end up defining HAVE_CLOSEFROM; I suppose I could have used `#if 1` as well.
I do hope the MR lands upstream, but development seems a bit bogged down there.