On Sat, 15 Feb 2003 [EMAIL PROTECTED] wrote:
> I've been tinkering with the queens.jako example, trying to make it work
> with strings
> instead of bit fields. Along the way, I had a parrot segfault aparently
> due to substr
> and a (null) string register. Its probably my fault such a call was being
> made, but
> I was surprised to see the result was a segfault.
>
> Consider this program:
>
> substr S0, 0, 1, " " # S0 is (null) here in a fresh interpreter
> print S0
> end
>
This segfaults because it calls string_replace, which expects both the
string that it is operating on and the replacement string to be valid;
in this case, S0 isn't a valid STRING, so... boom!
Note that the code:
set S0, ""
substr S0, 0, 1, S1 # S1 is (null) here in a fresh interpreter
print S0
end
also segfaults, for a similar reason.
> Should it:
>
> (a) Silently do something, such as print " " (but what if it were
> substr S0, 5, 2, " ")?
I strongly vote against this option: this form of the substr op is
designed to do an in-place modification of an existing string - if you're
using it with a non-existant target string, then this indicates a bug
in your code generation, and Parrot should assuredly complain about this
(if only by segfaulting :-)
> (b) Complain, but do something, such as print " " (same "what if"
> as above)?
> (c) Complain and die?
> (d) Be undefined behavior until we have exceptions, at which point
> it will (c)?
> (e) Something else?
>
> I think any time Parrot segfaults it represents a bug. If no external code
> has been
> loaded, it is a Parrot bug for sure.
>
>
> BTW, I added the above test to my local copy of t/op/string.t, but for
> whatever
> reason it doesn't segfault there. I would expect it to behave exactly as
> it does
> outside the harness, unless the harness is reusing an interpreter, which
> means
> its not testing what the code fragments would do in a fresh interpreter...
I have no idea what's going on here; it segfaults fine for me.
Simon
