[squeak-dev] Interesting Decompiler bug
Frank Shearar
frank.shearar at gmail.com
Thu Jun 20 09:14:50 UTC 2013
On 20 June 2013 02:12, David T. Lewis <lewis at mail.msen.com> wrote:
> On Thu, Jun 20, 2013 at 01:26:14AM +0200, Nicolas Cellier wrote:
>> See
>> http://stackoverflow.com/questions/17129583/smalltalk-collection-is-empty-error-when-saving/17202938#17202938
>>
>> This bug was found by a newbie on pharo 1.1, but it's still there in 4.5
>> trunk image
>>
>> Try to decompile this (no matter in which class)
>>
>> < aNumberWithUnits
>> (self compareUnits: aNumberWithUnits)
>> ifTrue: [self value: ((aNumberWithUnits value) < (self value)
>> ifTrue: [^true] ifFalse: [^false]).]
>> ifFalse: [^Error new signal: 'Incompatible unit types.'].
>>
>> Thanks to the newbie!
>> I would just have hated that!
>> Learning from one's own error is great, but from a dysfunctional system not
>> so :(
>
> Good bug catch! Here is a reduced version of the method that produces the
> same error when decompiled:
>
>
> Foo>>decompilerBug
> self value: (true
> ifTrue: [^ true]
> ifFalse: [^ false])
I'm guessing that this is because
true
ifTrue: [^ true]
ifFalse: [^ false]
decompiles as
true ifTrue: [^ true]
^ false
?
I'm not terribly worried about claims of a "dysfunctional system".
This bug is so severe that noone has noticed it before! I agree that
we need to fix the bug, but the original code makes no sense in the
first place. #value: is unreachable.
frank
> Dave
>
>
More information about the Squeak-dev
mailing list
|