> Don’t you think a file handle is a completely different thing than what is normally talked about with memory safety? Can a un-closed handle let you ++ your way into remote code execution? Or reading uninitialized memory?
Unfreed memory also doesn't let you ++ your way into remote code execution.
Using a file-handle after it's been closed can cause all sorts of issues; and if the underlying file-descriptor is being reused to e.g. write a shell script you can end up in RCE territory as well.
No, you can get an exception, but that can happen either way (the OS can close the file handler irrespective of what the process does), and is not a safety violation.
The only problem that can happen in managed languages is leaking of file handlers by not manually closing them, leaving it up to the GC, and opening handles faster than they are being closed — this can cause the OS to run out of handlers for the process, terminating it.
But this is not a big issue in practice in my experience, in Javac try-with-resources idiomatically solves this issue.
Unfreed memory also doesn't let you ++ your way into remote code execution.
Using a file-handle after it's been closed can cause all sorts of issues; and if the underlying file-descriptor is being reused to e.g. write a shell script you can end up in RCE territory as well.