Fix: Replace sighandler_t with sig_t for Apple and BSDs by chengr4 · Pull Request #5008 · rust-lang/libc

chengr4 · 2026-03-09T04:34:31Z

Description

This PR tries to fix #1273.

I am not able to evaluate whether #[deprecated] should be added.

Sources

Apple I checked at my local (Aarch MacOS 26.3.1)

(Freebsd) https://github.com/freebsd/freebsd-src/blob/016570c4463d5908953355ee1cf9a385ad9601b4/sys/sys/signal.h
(Dragonfly) https://github.com/DragonFlyBSD/DragonFlyBSD/blob/51591aff67978c86de99839e31d8c8fcc54bc316/sys/sys/signal.h
https://www.gnu.org/software/gnulib/manual/html_node/signal_002eh.html
The type sighandler_t (a GNU extension) is not defined on most non-glibc platforms: macOS 11.1
, FreeBSD 14.0, NetBSD 10.0, OpenBSD 7.5, AIX 5.1, HP-UX 11, Solaris 11.4, Cygwin, mingw, MSVC 14.

Checklist

Relevant tests in libc-test/semver have been updated
No placeholder or unstable values like *LAST or *MAX are
included (see #3131)
Tested locally (cd libc-test && cargo test --target mytarget);
especially relevant for platforms that may not be checked in CI

rustbot · 2026-03-09T04:34:34Z

Some changes occurred in a NetBSD-like module

cc @semarie

Some changes occurred in an OpenBSD module

cc @semarie

dybucc · 2026-08-02T08:49:38Z

Not sure if the author intends on finishing this up. If not, I've solved the
merge conflicts and (possibly) tweaked some the patchset at ¹.

Note these changes should be enough to close issue #1273, but it doesn't solve
the underlying problem with sigaction (which is prevalent across other
targets.) There's some places where it's used inappropriately.

https://github.com/dybucc/libc/commit/9f9458a9d3446d88d2b5dcbb8a837dbcaf34681e ↩

chengr4 · 2026-08-03T03:32:40Z

This PR was waiting for someone to review it for me. I can take another look after 8/9. If you have already resolved the issue and it is ready to merge, feel free to go ahead!

dybucc · 2026-08-03T10:16:48Z

Nay, just wanted to know if you were still on it. I did make some changes,
though, as I believe the actual definition will change once we settle on the
right bindings for siginfo_t across all targets (see #1359.)

But this PR can probably merged as the required changes once we get siginfo_t
right are minimal. Though I don't think we should deprecate it. siginfo_t
actually exists (with sort of mangled name) in FreeBSD ¹ ².

All other relevant targets (BSDs and Apple) can just rely on sig_t, as that's
their definition, while hiding sighandler_t in the docs for anything but
FreeBSD (and every target this PR doesn't change.)

It would be nice to have siginfo_t be an alias to the function and sig_t be
a pointer to this alias. But Rust doesn't allow function pointer decay through
function aliases when typedefining a function without prepending *.

tgross35

Sorry I've missed this, one request then LGTM. Please squash as well.

I think we should deprecate sighandler_t on platforms where it doesn't exist, adding __sighandler_t if that's relevant. But not something to do here.

View changes since this review

tgross35 · 2026-08-04T06:43:28Z

+#[cfg(any(
+    target_os = "macos",
+    target_os = "ios",
+    target_os = "tvos",
+    target_os = "watchos",
+    target_os = "visionos",
+    target_os = "freebsd",
+    target_os = "dragonfly",
+    target_os = "openbsd",
+    target_os = "netbsd"
+))]
+pub type sig_t = sighandler_t;


This can go in src/unix/bsd/mod.rs so we don't need the cfg

rustbot · 2026-08-04T06:53:35Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

chengr4 · 2026-08-09T06:14:29Z

@rustbot ready

rustbot · 2026-08-09T06:16:52Z

⚠️ Warning ⚠️

The following commits have merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.
- 1e9d098
You can start a rebase with the following commands:
```
$ # rebase
$ git pull --rebase https://github.com/rust-lang/libc.git main
$ git push --force-with-lease
```

rustbot · 2026-08-19T21:24:27Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot · 2026-08-19T21:24:28Z

⚠️ Warning ⚠️

The following commits have merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.
- 5526ab8
You can start a rebase with the following commands:
```
$ # rebase
$ git pull --rebase https://github.com/rust-lang/libc.git main
$ git push --force-with-lease
```

madsmtm · 2026-08-19T21:29:22Z

+// going to need tweaking because raw pointers to functions aren't a thing just
+// yet in Rust.


Isn't Option<unsafe extern "C" fn()> basically a raw pointer to a function?

View changes since the review

Kind of but in a very footgunny way, IMO. #4998 and the thread https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/type.20representing.20raw.20function.20pointers/with/606804857

Introduce new alias `sig_t` to `sighandler_t` for both Apple and BSD targets. Replace all uses of `sighandler_t` with `sig_t` in Apple and BSD targets. These platforms don't use the GNU-specific extension that `sighandler_t` is. See the following list for details on each system. - Apple: <https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/bsd/sys/signal.h#L501> - FreeBSD: <https://github.com/freebsd/freebsd-src/blob/77d6c45afdca8a524a88edfb3097d4d9dc90b583/sys/sys/signal.h#L160> - DragonFlyBSD: <https://github.com/DragonFlyBSD/DragonFlyBSD/blob/e8a62118fe4823bb5982e5d759e5ffaa6b6aae21/sys/sys/signal.h#L257> - NetBSD: <https://github.com/NetBSD/src/blob/5c8b04300c02b550f331bc0b7357f0fc71909aaa/sys/sys/signal.h#L247> - OpenBSD: <https://github.com/openbsd/src/blob/f8480ad0276ad54ce9f7ed2b2004c86f9f1a9521/sys/sys/signal.h#L148> Note this patch doesn't try to fix the `sigaction` situation where most systems use a specific field of the upstream `union` in its first field. That is work for another patchset (and further discussion.) Co-authored-by: Adam Martinez <149513579+dybucc@users.noreply.github.com>

tgross35 · 2026-08-20T10:31:57Z

+// FIXME(1.0): once we settle for a definition for `sighandler_t`, ensure it's
+// sound for `sig_t` to be a raw pointer to it, as that's the definition in the
+// BSDs and Apple targets.
+//
+// See <https://github.com/freebsd/freebsd-src/blob/77d6c45afdca8a524a88edfb3097d4d9dc90b583/sys/sys/signal.h#L160>
+// and <https://github.com/freebsd/freebsd-src/blob/77d6c45afdca8a524a88edfb3097d4d9dc90b583/sys/sys/signal.h#L408>
+// for FreeBSD details.
+//
+// Because `sighandler_t` is defined in FreeBSD as a function alias that
+// implicitly decays to the function pointer and not a "straight" alias to a
+// function pointer, we can probably keep the same definitions in other BSDs.
+//
+// They have no `sighandler_t` but do have the same `sig_t`. Of course, this is
+// going to need tweaking because raw pointers to functions aren't a thing just
+// yet in Rust.
+pub type sig_t = *const crate::sighandler_t;


Actually, reading things closer since Mads pointed it out, I think this should just be a type sig_t = Option<unsafe extern "C" fn(c_int)> and then sighandler_t needs to be deleted. Opsem says that's sound even for non-dereferenceable values, which was one of the questions in the past. The other question is whether or not it's a footgun, which I still think it is, but that applies to all function pointers in this crate.

Sorry for adding another change, but I think that gets us closer to where we want to be. You can also drop this comment since it will only have the problem that all function pointers have, and I don't think there's anything really worth noting about the FreeBSD definition (but do feel free to put any of it into the commit message).

View changes since the review

Also it looks like you need to recheck the semver files based on the CI failure.

rustbot added the S-waiting-on-review label Mar 9, 2026

chengr4 changed the title ~~Sig t~~ Fix: Replace sighandler_t with sig_t for Apple and BSDs Mar 9, 2026

chengr4 force-pushed the sig_t branch from d198f5d to d9d5db8 Compare March 9, 2026 04:54

This comment has been minimized.

Sign in to view

tgross35 mentioned this pull request Aug 4, 2026

Incorrect type name sighandler_t should be sig_t on apple targets #1273

Open

tgross35 requested changes Aug 4, 2026

View reviewed changes

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Aug 4, 2026

chengr4 force-pushed the sig_t branch from d9d5db8 to b6f3201 Compare August 9, 2026 06:07

rustbot added O-bsd O-dragonfly O-freebsd O-macos O-unix labels Aug 9, 2026

rustbot added S-waiting-on-review and removed S-waiting-on-author labels Aug 9, 2026

This comment has been minimized.

Sign in to view

chengr4 force-pushed the sig_t branch from 1e9d098 to fc31ffe Compare August 9, 2026 06:21

tgross35 enabled auto-merge August 12, 2026 07:36

This comment has been minimized.

Sign in to view

madsmtm reviewed Aug 19, 2026

View reviewed changes

auto-merge was automatically disabled August 19, 2026 21:56
Head branch was pushed to by a user without write access

chengr4 force-pushed the sig_t branch from 5526ab8 to 930ef42 Compare August 19, 2026 21:56

tgross35 requested changes Aug 20, 2026

View reviewed changes

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Aug 20, 2026

		// going to need tweaking because raw pointers to functions aren't a thing just
		// yet in Rust.

Uh oh!

Conversation

chengr4 commented Mar 9, 2026 • edited by tgross35 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Sources

Checklist

Uh oh!

rustbot commented Mar 9, 2026

Uh oh!

This comment has been minimized.

dybucc commented Aug 2, 2026

Footnotes

Uh oh!

chengr4 commented Aug 3, 2026

Uh oh!

dybucc commented Aug 3, 2026

Footnotes

Uh oh!

tgross35 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Aug 4, 2026

Uh oh!

chengr4 commented Aug 9, 2026

Uh oh!

This comment has been minimized.

rustbot commented Aug 9, 2026

Uh oh!

This comment has been minimized.

rustbot commented Aug 19, 2026

Uh oh!

rustbot commented Aug 19, 2026

Uh oh!

madsmtm Aug 19, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Aug 20, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Aug 20, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

chengr4 commented Mar 9, 2026 •

edited by tgross35

Loading

tgross35 left a comment •

edited

Loading

madsmtm Aug 19, 2026 •

edited by rustbot

Loading

tgross35 Aug 20, 2026 •

edited

Loading

tgross35 Aug 20, 2026 •

edited by rustbot

Loading