ChipTuner on Nostr: Quite interesting. I'm an aggressive null checker. Internal functions are mostly ...
Quite interesting.
I'm an aggressive null checker. Internal functions are mostly debug if null is like a static control flow error.
Address 0x9c should be a protected region so worst that could happen was a crash? If I'm not mistaken the process dump showed an protected read fault.
Top voted comment on HN suggests (just like I would) "This should not have passed a competent C/I pipeline for a system in the critical path."
But besides banging on my keyboard, software bugs are going to happen. Adding more complexity is unlikely to fix the issue for a long time. Maybe would shouldn't depend on things where a single mistake in a single line of code (that was found) causes the world to nearly melt down. We've had memory safe languages for a long time, guess what, programmer errors still cause application crashes. Also many (if not all) "safe" languages just defer the unsafe stuff to the compiler/interpreter. The majority of the C# standard library uses pointers and P/Invoke.
Lets just keep making tool-chains larger and supply chains deeper I guess until the problem is resolved... because that works. I'm done.
I'm an aggressive null checker. Internal functions are mostly debug if null is like a static control flow error.
Address 0x9c should be a protected region so worst that could happen was a crash? If I'm not mistaken the process dump showed an protected read fault.
Top voted comment on HN suggests (just like I would) "This should not have passed a competent C/I pipeline for a system in the critical path."
But besides banging on my keyboard, software bugs are going to happen. Adding more complexity is unlikely to fix the issue for a long time. Maybe would shouldn't depend on things where a single mistake in a single line of code (that was found) causes the world to nearly melt down. We've had memory safe languages for a long time, guess what, programmer errors still cause application crashes. Also many (if not all) "safe" languages just defer the unsafe stuff to the compiler/interpreter. The majority of the C# standard library uses pointers and P/Invoke.
Lets just keep making tool-chains larger and supply chains deeper I guess until the problem is resolved... because that works. I'm done.