Mark schedule_with_runloop/unschedule_from_runloop as unsafe

[faern]

This is an API breaking change. Mark SCNetworkReachability::schedule_with_runloop and unschedule_from_runloop as unsafe. They accept a raw pointer that it dereferences (this library does not, but it's passed on to Apple libraries that might).

Figuring out a safe API around this is left as an exercise for the future or external contributors.

---

This change is 

[dlon]

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved

---

system-configuration/src/network_reachability.rs line 199 at r1 (raw file):

        run_loop_mode: CFStringRef,
    ) -> Result<(), SchedulingError> {
        if unsafe {

Nit: Pointless unsafe

[faern]

Reviewable status: 1 of 2 files reviewed, all discussions resolved (waiting on @dlon)

---

system-configuration/src/network_reachability.rs line 199 at r1 (raw file):

Previously, dlon (David Lönnhager) wrote…

Nit: Pointless unsafe

Soon it won't be 😅 Luckily we change this madness in Rust 2024 to require unsafe blocks in unsafe functions as it should have always been ;) rust-lang/rfcs#2585

But the CI is complaining, so I guess we have to remove it for now. Add it back when switching to Rust 2024

[dlon]

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved

---

system-configuration/src/network_reachability.rs line 199 at r1 (raw file):

Previously, faern (Linus Färnstrand) wrote…

Soon it won't be 😅 Luckily we change this madness in Rust 2024 to require unsafe blocks in unsafe functions as it should have always been ;) rust-lang/rfcs#2585

But the CI is complaining, so I guess we have to remove it for now. Add it back when switching to Rust 2024

TIL. That seems very reasonable.