While there was a lot of talk in this thread about how we were not going to
provide extra
checks to prevent segfaults... both the original case and the simple one below
no longer
generate segfaults, but instead throw an exception of some kind.
Closing ticket.
> [EMAIL PROTECTED] - Tue Jul 29
On Tue, Jul 29, 2003 at 08:31:56PM -0400 it came to pass that Dan Sugalski wrote:
> That's ultimately the plan. There'll be a safe version of all the
> ops, automatically generated, that perform some basic checks--for
> example making sure all the pointer-based registers are valid.
> This'll be
At 20:54 -0300 7/29/03, Daniel Grunblatt wrote:
On Tuesday 29 July 2003 21:10, chromatic wrote:
On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote:
> Therefore the decision was taken that we should not guarantee that
> Parrot
> should never segfault when fed bad assembler; the creatio
On Tuesday 29 July 2003 21:10, chromatic wrote:
> On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote:
> > 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 bu
On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote:
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.
If people write P
Simon Glover wrote:
Therefore the decision was taken that we should not guarantee that Parrot
should never segfault when fed bad assembler;
... in the "fast run case", but we will provide a save environment, that
does do all kinds of bounds checking, check byte code, have a reduced
and config
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, si
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 wo
--- Jos Visser <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Jos Visser
> # Please include the string: [perl #23159]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=23159 >
>
>
> --
# New Ticket Created by Jos Visser
# Please include the string: [perl #23159]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23159 >
Description:
10 matches
Mail list logo
