Re:Why you should, actually, rewrite some of it in Rust
by CalChris on Wednesday July 12, 2017 @03:18PM
(#14755683)
setjmp wasn't even supported. I had to use an LLVM intrinsic. This only barely worked if I put the setjmp and the longjmp in separate files.
[ Parent
| on HN ]
Re:Why you should, actually, rewrite some of it in Rust
by Rusky on Wednesday July 12, 2017 @03:23PM
(#14755737)
Why is setjmp such a major issue for you? It's a C language feature, not a "real low level to the metal systems programming" requirement.
Re:Why you should, actually, rewrite some of it in Rust
by CalChris on Wednesday July 12, 2017 @03:29PM
(#14755790)
If you are calling C or assembly and there is any sort of processor exception, you need to establish a signal() handler and you will need setjmp/longjmp to re-establish a safe stack frame.
Yes, this is a C/assembly thing. But it is also a Linux/BSD/Unix thing. You really cannot call Rust a systems programming language if signal/setjmp/longjmp are not fully supported. It just goes with the territory.
Re:Why you should, actually, rewrite some of it in Rust
by Rusky on Wednesday July 12, 2017 @04:37PM
(#14756437)
Linux/BSD/Unix are hardly the only systems programming environments. I'd hesitate even to call them the majority.
And for now, there are definitely ways to handle signals using libraries.
Re:Why you should, actually, rewrite some of it in Rust
by lossolo on Wednesday July 12, 2017 @07:40PM
(#14757615)
> Linux/BSD/Unix are hardly the only systems programming environments. I'd hesitate even to call them the majority.
Do you have any source that can confirm that? Because what you wrote seems really wrong. I see linuxes/bsd/unix EVERYWHERE (Android/iOS/OSX/almost all backend servers etc.)