Thanks, Marcel. Yes, I thought you might enjoy this little holiday from "industrial" programming ;)

BTW, no criticism was ever intended of the creators of either SMSQ/E or DISA! Bugs are a fact of life, and not even Nature is imune (My brain is full of them, for starters - and thats not the inter-festive DT's talking!) The deeply philosophical line 5 (in the light of line 4) in the first code sample, is for anyone to ponder in the New Year - for which I wish y'all a happy one!..

On 30/12/2017 13:39, Marcel Kilgus via Ql-Users wrote:
pjwitte via Ql-Users wrote:
If you want a really miserable Christmas, you could try the following
- without saving your work first:

1 x% = 32000
2 y% = x%
3 z% = 1600
4 t  = x% * y% * z%: REMark Kaboooom!!!
5 PRINT "-<GROAN>- Im dead!"
Nice find and, as usual, good repro, thanks. As good as TT's code
usually is, here he has used too many "magic numbers" instead of
speaking EQU symbols and promptly used the wrong number (6 instead of
8) when calculating a code offset. I will send Wolgang the fix for the
next release.

What's happening:

1. "x% * y%" is "int16 * int16" and results in an "int32"
2. Then z% in "* z%" is promoted to "int32" so the operation is "int32 * int32"
3. It checks if the result will overflow, which it will in this case,
    so the operands are converted to "float" and it retries again using the
    "float * float" code path
4. But the code to retry jumps back into the "int32 * int32" path instead
    of the "float * float" path and hilarity ensues. This path has never
    worked since the dawn of SBasic :-o

The above crashes SMSQ/E 3.32 on QPC2 and SMSQmulator! Even the
four-finger reset wont work. The following is, as youd expect, fine:

1 x% = 32000
2 y% = x%
3 z% = 1600
4 t  = x% * y%
5 t  = t * z%
6 PRINT "Yippi! - Im still alive!"
"t" is float in this case, so "t * z%" is "float * int16". In this
case z% is promoted into a float, so the operation is "float * float"
from the start and everything is happy.

QL-Users Mailing List

Reply via email to