LOAD memory leak

It might just be a reformatting procedure, but—

COMMON DEF T S$
VAR A$
LOAD S$,0OUT A$
STOP
END

Edit: added COMMON and removed space before OUT After you call T with a valid file extension and name within S$ (ex. "TXT:FILE") print the variable S$ on the console. The contents of the string have been modified as a result of the load instruction. If you print S$ during runtime, the anomaly does not occur. I'm not sure what the modified string characters are for, I can only guess that it's SB's way of converting the name and extension into something the file system can use.

I can't get it to happen. Are you sure this is the exact code you're using?

I can't get it to happen. Are you sure this is the exact code you're using?

I have restarted my system and tested the code again. I will rewrite the code exactly as I have it, though it really doesn't differ. Edit: I'm using the N3DS, and version 3.3.2

I can reproduce it on US 3.5.2. Upon some testing, this has nothing to do with LOAD. The following program does the same thing:

COMMON DEF T S$
 STOP
END

Steps to reproduce: 1. Type the above program into Slot 0. 2. Go back to Direct mode and press Start to run it. 3. Type T"Some string" in Direct mode and press A. 4. Type ?S$ in Direct mode and press A. Interestingly enough, though only the first five characters were corrupted for me, upon writing a FOR loop that would iterate over each character and print it in hex, the entire string became corrupted. My theory is that S$ ends up actually pointing to freed memory. Something else notable is that CLEAR failed to clear S$, though writing a new program and running that did clear it.

You skipped step 2. You have to press Start to load the program, otherwise T won't be recognized.

You skipped step 2. You have to press Start to load the program, otherwise T won't be recognized.

Your example program is missing the T. That's the problem. I followed your steps exactly.

oh it's COMMON DEF I didn't see that before.

Ah, crap, you're right. Typo.

Wow, this is interesting. I didn't bother to take the load instruction out and test it, I just figured it was related. So, it would appear to me that the STOP instruction is what's causing this. Guess I should rename this so. Edit: can't rename the heading. Lol oh well, I'm curious to see what other quirks this presents.

A few strange things: 1: function must be COMMON 2: program must be stopped from inside the function 3: function must be called from direct mode 4: a string literal (not a variable) must be passed to the function

A few strange things: 1: function must be COMMON 2: program must be stopped from inside the function 3: function must be called from direct mode 4: a string literal (not a variable) must be passed to the function

Those are some very specific demands for this bug. Interestingly, if you tell the function to print S$ after the STOP instruction, and CONT the execution after calling T, the string will be printed unwaveringly, but if you chose to print the variable from DIRECT mode after STOPping, continuing the execution will print the faulted string.