News for hackers. Stuff that matters.
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.
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.)

Re:Why you should, actually, rewrite some of it in Rust by Rusky on Wednesday July 12, 2017 @08:49PM (#14757974)
I'm thinking of embedded systems and desktop machines- the first tends not to use an OS nearly that big (if any at all), and the second tends to use Windows.