[FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

Klaus D. Witzel klaus.witzel at cobss.com
Sun Jul 23 21:16:49 UTC 2006


It works, your and my example no longer fail.

Is there a routine to check the modified Decompiler against all source  
coded methods?

/Klaus

On Sun, 23 Jul 2006 16:23:31 +0200, Bert Freudenberg wrote:

> Simpler test case - in a Browser, add this method:
>
> test
> 	(self foo; bar)
> 		ifTrue: [1]
> 		ifFalse: [2]
>
> Then switch to "decompile" instead of "source".
>
> If the receiver of an ifTrue:ifFalse: is a cascade, the decompiler
> mistakes it for a case statement. I attached a fix for that, could
> someone please verify?
>
> - Bert -
>
>
> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>
>> Sorry, hyperlink is
>>
>> - http://bugs.impara.de/view.php?id=4313
>>
>> /Klaus
>>
>> On Sat, 22 Jul 2006 23:37:07 +0200, Klaus D. Witzel
>> <klaus.witzel at cobss.com> wrote:
>>
>>> http://bugs.impara.de/view.php?id=2921
>>>
>>> You can provoke the emergency console by having Decompiler fail
>>> with self error:'bad case' in #send:super:numargs.
>>>
>>> The following trivial, innocent looking code snippet does it in
>>> 3.8 and 3.9:
>>>
>>> | x y |
>>>   x := y := 0.
>>> {'a'. 'b'. 'c'} do: [:c|
>>>      (c string halt; endsWith: 'd')
>>>          ifTrue: [x:= 1 + x]
>>>          ifFalse: [y:= 1 + y]]
>>>
>>> Strange, why should Decompiler be involved in a halt situation,
>>> and then, why should it refuse to decompile code?
>>>
>>> /Klaus
>>>
>>>
>>>
>>
>>
>>
>





More information about the Squeak-dev mailing list