It could. We haven't seen the code but it could be something like: char *ptr = p...

ArtixFox · 2024-07-20T18:03:32.000000Z

unhandled null in rust will still cause panic. still cause the bootloop.

YZF · 2024-07-20T18:18:05.000000Z

I'm not a Rust expert but wouldn't you pick some ("null-safe") type that can't be null in Rust? A reference?

ArtixFox · 2024-07-20T18:37:15.000000Z

i dont think it matters, if you have any exception in the critical boot part, you will end up with this. Rust cannot fix this. Microkernels might.

YZF · 2024-07-20T22:12:17.000000Z

Something like this Go snippet:

  func parsefile(string) string {
  }

  func thatfunctionthatcrashedinC() {
      defer func() {
      if err := recover(); err != nil {
        log.Println("panic occurred:", err)
      }
    }()
    result := parsefile(badfilethatcrashesC);
    if result[0] == 'A' {
    }
  }

so... using a type that can't be nil. recovering from runtime panics (you have to do that but this can be enforced by standards and also it can happen up the stack for all code, e.g. like http handlers do by default in the Go standard library). More importantly these errors are not segfaults in Go, i.e. there's "exceptions" you can and should catch and there are exceptions you can't.

ArtixFox · 2024-07-21T02:35:38.000000Z

You have all that in C++ too. Exceptions are near zero cost and used everywhere, sometimes even in embedded stuff too.

YZF · 2024-07-21T04:34:32.000000Z

Sure. I speak C++ ;) You can do this in C++ but I think it's generally more crash prone than Go. Based on personal experience of ~20 years of C++ and ~10 of Go I've debugged many a core dump in C++ and I think zero in Go. You can restrict yourself to the somewhat safer parts of C++ for sure.