(SmallInteger new: 0) can quickly lead to a VM crash. This should better be intercepted as a primitive failure. I know that we cannot protect against all and every mistake, but this one should be easy.
See http://stackoverflow.com/questions/20621119/how-to-print-an-integer-to-trans...
I'm thinking of Spur where Character are immediate and where archeo-code could lead to same kind of crash.
Hi Nicolas,
good catch. thanks.
On Mon, Dec 16, 2013 at 2:36 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
(SmallInteger new: 0) can quickly lead to a VM crash. This should better be intercepted as a primitive failure.
greed. But there are two obvious ways to go about this (at least in Spur). One is to explicitly test for the immediate classes in the new and new: primitives. This is poor as it introduces additional tests on a critical path. The other way is to give SmallInteger and Character special formats and then the primitives would fail without additional tests. The question is what format to use. In Spur the formats are
0 = 0 sized objects (UndefinedObject True False et al) 1 = non-indexable objects with inst vars (Point et al) 2 = indexable objects with no inst vars (Array et al) 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al) 4 = weak indexable objects with inst vars (WeakArray et al) 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron) 6 unused, reserved for exotic pointer objects? 7 Forwarded Object, 1st field is pointer, rest of fields are ignored 8 unused, reserved for exotic non-pointer objects? 9 (?) 64-bit indexable 10 - 11 32-bit indexable (11 unused in 32 bits) 12 - 15 16-bit indexable (14 & 15 unused in 32-bits) 16 - 23 byte indexable (20-23 unused in 32-bits) 24 - 31 compiled method (28-21 unused in 32-bits)
Format 7 should never be valid for an instance as it is reserved by the VM for forwarders. So how about making 7 the format for immediate classes? Ten it will be easy to arrange that both new and new: will fail naturally for this format.
I know that we cannot protect against all and every mistake, but this one
should be easy.
See http://stackoverflow.com/questions/20621119/how-to-print-an-integer-to-trans...
I'm thinking of Spur where Character are immediate and where archeo-code could lead to same kind of crash.
or just implement SmallInteger class>>new:, etc, to signal an error without bothering the primitive at all.
On 12/16/13 8:59 PM, Eliot Miranda wrote:
Hi Nicolas,
good catch. thanks.On Mon, Dec 16, 2013 at 2:36 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
(SmallInteger new: 0) can quickly lead to a VM crash. This should better be intercepted as a primitive failure.greed. But there are two obvious ways to go about this (at least in Spur). One is to explicitly test for the immediate classes in the new and new: primitives. This is poor as it introduces additional tests on a critical path. The other way is to give SmallInteger and Character special formats and then the primitives would fail without additional tests. The question is what format to use. In Spur the formats are
0 = 0 sized objects (UndefinedObject True False et al) 1 = non-indexable objects with inst vars (Point et al) 2 = indexable objects with no inst vars (Array et al) 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al) 4 = weak indexable objects with inst vars (WeakArray et al) 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron) 6 unused, reserved for exotic pointer objects? 7 Forwarded Object, 1st field is pointer, rest of fields are ignored 8 unused, reserved for exotic non-pointer objects? 9 (?) 64-bit indexable 10 - 11 32-bit indexable(11 unused in 32 bits) 12 - 15 16-bit indexable(14 & 15 unused in 32-bits) 16 - 23 byte indexable(20-23 unused in 32-bits) 24 - 31 compiled method(28-21 unused in 32-bits)
Format 7 should never be valid for an instance as it is reserved by the VM for forwarders. So how about making 7 the format for immediate classes? Ten it will be easy to arrange that both new and new: will fail naturally for this format.
I know that we cannot protect against all and every mistake, but this one should be easy. See http://stackoverflow.com/questions/20621119/how-to-print-an-integer-to-transcript I'm thinking of Spur where Character are immediate and where archeo-code could lead to same kind of crash.-- best, Eliot
vm-dev@lists.squeakfoundation.org
-
Bob Arning -
Eliot Miranda -
Nicolas Cellier