Jarkko Hietaniemi wrote:
Joshua Hoblitt via RT wrote:
It's a test failure for unimplemented feature(s). There is already a
TODO ticket (bug #31178) that ruffly covers this. Can you make a case
for why it needs to be to tracked as a software defect?
A core dump is a software defect, an unacceptable failure, doesn't
matter whether it is from an assert or not. If Parrot's
development thinks differently or uses different terms, fine,
close the ticket.
The core dump is caused by a TODO test, which tests 'features' that will
be removed anyway. The test does something like:
new P0, Undef
read S0, P0, 1
Citing chip from the other ticket #31178:
[TODO] IO - off with its head! er, opcodes!
IO doesn't belong as opcodes.
Design a standard IO library ... base it on something sane that already
exists ... and get all those IO functions the heck out of our opcode
space.
---
That means, that the C<read> opcode (and some other IO opcodes) will be
removed and replaced by a ParrotIO method. Calling "read" on a PMC that
can't "read" will just throw a "method not found" exception and this
case is resolved.
Anybody might decide, how many open tickets we need for this, and how
severe this one segfault is.
leo
