[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