[re-cc'd p6i due to mailer failure on my part]
>At 10:17 PM 5/22/2002 +0000, via RT wrote:
>Clinton A. Pierce wrote:
>
>> * sync up, and get the latest Parrot BASIC. It's fully hash-enabled and
>> quite speedy now.
>>
>> * Run "basic.pl" to assemble the interpreter, and get it started
>>
>> * At the "Ready" prompt, "LOAD eliza"
>>
>> * When finished, type RUN
>>
>> The crash will happen shortly thereafter. Comments in #parrot seem to
>
>The problem appears to originate in the routine SFETCH, which tries to fetch
>key "TWIRL" from the hash in P21 without finding it. The hash code returns a
>null pointer under these circumstances, which is accepted as an empty string
>by some, but not all, string handling code. In this case, attempting to
>store the string into an array is invoking string_copy, which assumes the
>input to be valid. IIRC Dan stated some time ago that checks for null were
>not to be included, but I don't know what the current status is.
A patch to add isnull was submitted today, which is one potential way of
handling it. Another is to not have get_keyed return the NULL in the first
place. I favor the latter, because there's no other way that I'm aware of
in PASM to get an Sx register with a NULL in it, why start introducing this
now? It seems unclean.
(But a patch oftentimes speaks louder than opinions.)
So temporarily I patched basicvar.pasm so that instead of:
SFETCH: pushs
pushi
restore S0 # Name
get_keyed S1, P21, S0
save S1
popi
pops
ret
I do this as I'm fetching the (possibly non-existent) value from the hash:
SFETCH: pushs
pushi
restore S0 # Name
get_keyed S1, P21, S0
length I0, S1
ne I0, 0, SNOTNULL
set S1, ""
SNOTNULL: save S1
popi
pops
ret
Because length Ix, Sx seems to be immune from the NULL problem. Now BASIC
and all of its demo programs run without a hitch. This could easily be
fixed with "isnull Sx, label" also.
