On Tue, 29 Jul 2003, Jos Visser wrote:
> On Tue, Jul 29, 2003 at 09:11:15AM -0700 it came to pass that Mr. Nobody wrote:
> > I don't think it's worth adding extra overhead to lexical variables just to
> > support broken pasm. There are many ways to crash parrot with bad code - but
> > it's OK, since compilers of higher level languages simply won't generate
> > them. :)
>
> I would call an "if (!pad) return 0;" hardly extra overhead (4
> instructions on an Intel x86). There is a lot of stuff you can not do
> if this is the sort of overhead you are worried about.
>
> I was unaware that the entire parrot VM can crash due to bad code.
It's actually extremely easy to do; for instance, this:
set I0, P10
end
will segfault since Parrot tries to call get_integer on a NULL PMC (since
there's nothing in P10 at startup).
Now, this segfault can be avoided, just as the one you point out above
can be avoided, but only at the cost of adding extra checks. The problem
is that you wind up needing a LOT of these, if you're to guarantee that
Parrot will never segfault when given bad code. So: in the individual
case, the cost is not much (although branches are icky on modern
processors due to deep pipelines), but in the aggregate it will be
considerably more.
Therefore the decision was taken that we should not guarantee that Parrot
should never segfault when fed bad assembler; the creation of invalid
assembler is a compiler bug, and should be fixed at the compiler level.
(Note, however, that we should never segfault on _valid_ assembler).
Hope that clarifies things, and thanks for the report and for the patch
(even if we don't end up applying it).
Simon
