> 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