]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdbsupport/scoped_ignore_signal.h
gdb: don't pass nullptr to sigwait
authorAndrew Burgess <aburgess@redhat.com>
Wed, 29 Dec 2021 11:53:49 +0000 (11:53 +0000)
committerAndrew Burgess <aburgess@redhat.com>
Tue, 4 Jan 2022 10:28:19 +0000 (10:28 +0000)
commit926ac872e924e6618441f76917d58088d92dd11d
tree01d85e83aeaa509f7455d3577dc0591f57f8481d
parente2c0cef94da679745201317a0da0228f0f50158b
gdb: don't pass nullptr to sigwait

I tried building GDB on GNU/Hurd, and ran into this warning:

  gdbsupport/scoped_ignore_signal.h:78:16: error: null argument where non-null required (argument 2) [-Werror=nonnull]

This is because in this commit:

  commit 99624310dd82542c389c89c2e55d8cae36bb74e1
  Date:   Sun Jun 27 15:13:14 2021 -0400

      gdb: fall back on sigpending + sigwait if sigtimedwait is not available

A call to sigwait was introduced that passes nullptr as the second
argument, this call is only reached if sigtimedwait is not supported.

The original patch was written for macOS, I assume on that target
passing nullptr as the second argument is fine.

On my GNU/Linux box, the man-page for sigwait doesn't mention that
nullptr is allowed for the second argument, so my assumption would be
that nullptr is not OK, and, if I change the '#ifdef
HAVE_SIGTIMEDWAIT' introduced by the above patch to '#if 0', and
rebuild on GNU/Linux, I see the same warning that I see on GNU/Hurd.

I propose that we stop passing nullptr as the second argument to
sigwait, and instead pass a valid int pointer.  The value returned in
the int can then be used in an assert.

For testing, I (locally) made the change to the #ifdef I mentioned
above, compiled GDB, and ran the usual tests, this meant I was using
sigwait instead on sigtimedwait on GNU/Linux, I saw no regressions.
gdbsupport/scoped_ignore_signal.h