impossible fromPrimitiveWithAssert(<null>) in some cases when attempting to readall from a nonexistant file; repro attached

[dewiniaid]

Invoking the attached script with:

CLEARSCREEN. SWITCH TO 1. COPY kinstall_broken FROM 0. RUN kinstall_broken

yields:

kOS.Safe.Exceptions.KOSException: Internal Error.  Contact the kOS developers with the phrase 'impossible FromPrimitiveWithAssert(<null>) was attempted'

Both the full output_log and a stripped down version are attached; search for --MARK-- to find the correct location.

The ultimate cause appears to be on line 446:
LOCAL data IS vol:open(file):readall().
when file does not exist.

It looks like it may be reducible to a one-liner, but not always:

core:currentvolume:open("nonexistant")  // asserts
archive:open("nonexistant")  // asserts
open("nonexistant")  // correctly throws File does not exist.

Also, I'm fully aware that the sample .ks attached is a) ridiculous and b) buggy. a) is half the reason for doing it. (Why not implement a kOS parser/dependency scanner/code optimizer/minifier/installer in... kOS)

[dewiniaid]

KOSFailedAssert.zip

Helps if I attach the file.

[Dunbaratu]

A design decision made a while ago I was never entirely happy with was to never ever expose user scripts to the concept of "nulls". (IMO, nulls are important because they're a way for a method to return a signal value that means "I can't do that, sorry", but in a way you can trap for that doesn't crash the program with an error message before you get your hands on it.)

So basically, the root cause of the problem in kOS here is that vol:open(file) should never be returning a null, EVER, because of that aforementioned design decision. Instead it has to bomb out with a KOSException of some sort, and if you want to prevent that in your script or account for it in your script you have to call a different protection check function to see if the file exists first.

Once a part of the kOS system does return a NULL and put it on the stack, then the system breaks because we're not supposed to have anything on the stack that's not derived from our own types, and the native NULL is sort of not-a-type at all.

[dewiniaid]

That doesn't fully explain why the third test case OPEN("nonexistant") properly gives a FileNotFound when the first two don't -- is it not internally implemented as a shortcut to core:currentvolume:open(...)?

[hvacengi]

There's a chance this was fixed with the sub-directories pull request (#1567) but the reason that the first two cases differ from the third case is that the function open had a different implementation than the volume suffix open. I'll try to test this in the current develop branch to confirm if it has been fixed, or not.