Gregory's Server
@marcan Here broken piece of input comes, and your memory safe code dies with exit code 9000. I mean, this whole situaiton when faulty driver can cause crash whole system instead of markng this driver as faulty and to not not use it at next boot, and if necessary, reboot with new settings, or use special fallback driver whose purpose would be to report about problem on next reboot, and then it would be quite short outage and systems would be alive after few reboots, read - few minutes max.
|
2 comments
@marcan @koteisaev even panicking would be better than null pointer deref, panics clearly point at the offending driver, and the os can use that information to reboot with the driver blacklisted (or increment a failure counter, or whatever else policy would be appropriate)
|
@koteisaev If your memory safe driver returns error 9000 from the initialization routine, your system does not BSOD. Instead you get an exclamation point in Device Manager or what have you. That's the whole damn point. Memory safe (and well designed) languages like Rust force you to think about error handling. Yes there is
panic, but it is possible to forbidpanicby policy/compiler options and truly force all code to use error handling for every possible corner case, and then your code provably cannot BSOD the system (at least not with memory errors, obviously a failure of the storage driver can still lead to a "can't mount filesystem" BSOD but we're not talking about that here).@koteisaev If your memory safe driver returns error 9000 from the initialization routine, your system does not BSOD. Instead you get an exclamation point in Device Manager or what have you. That's the whole damn point. Memory safe (and well designed) languages like Rust force you to think about error handling. Yes there is
panic, but it is possible to forbidpanicby policy/compiler options and truly force all code to use error handling for every possible corner case, and then your code provably