3 ms·
The "fault" lies with any function which fails to uphold its contract. I would argue that if `foo1` were documented as async-signal safe, then it would be at fa
by ridiculous_fish 4y ago
The "fault" lies with any function which fails to uphold its contract. I would argue that if `foo1` were documented as async-signal safe, then it would be at fault for the memory corruption it causes, if called from a signal handler.
- burntsushi 4y ago> I would argue that if `foo1` were documented as async-signal safe Agreed there, certainly. But that doesn't have much to do with Rust's safety/soundness stuff, and is more just about adhering to documented contracts. And 'foo1' is not documented as async-signal safe here. I generally wouldn't rely on any function to be async-signal safe unless it's explicitly documented to be. I'm sure there's probably a heap of std methods where it would be reasonable to assume async-signal safety, particularly ones that don't do I/O, wouldn't reasonably be expected to allocate and are documented to never panic. (Possibly other things, I don't have the requirements for async-signal safety memorized. I just know to be super paranoid and carefully pay attention to it if I'm writing a signal handler. Which is... one of the many reasons I avoid signal handlers if I can help it and instead use something like the `signal-hook` crate.)