Tokeniser: Binary Numbers larger than 32-bit Truncated or Masked #4

New Issue

john · 2023-03-25T15:36:07Z

john commented

2023-03-25 15:36:07 +00:00

Ref 1.06

The AMOS(Pro) editor can't handle numbers that won't fit in 32 bits. They are changed into a lower
number.
Examples:
%111111111111111111111111111111111 (33 bits) will change into 1111111111
Tested with
AMOSPro V2.00 uncompiled - has the bug
AMOSPro V2.00 compiled - not tested yet
AMOS V1.36 uncompiled - not tested yet
AMOS V1.36 compiled - not tested yet
Credits

bug discovery/description by Spellcoder (Mark de Jong) on 24-sep-2007
http://www.amigacoding.com/index.php?title=AMOS:Bug_Large_numbers_in_editor&oldid=217
Cause
When the length exceeds 32 digits, a branch to the wrong label causes the code to continue in the
middle of a decimal conversion routine. This gives a garbage result and flags it as okay.
Solution
Branch destination label corrected.
Not the full solution! The Editor's tokeniser ignores the detail in the reply from the evaluation routine:

0
Evaluation overflow (the one we're interested in)
0
OK, we got a number
<0
Not a number
So it skips the set of digits that it's just tried to evaluate and carries on as if nothing was wrong!
This applies to ALL numeric formats for integers. For example $123456789 would overflow and fail
too.

Marked as In Progress by bruceuncle

+ILib.s
+Lib.s
V2.10.002
V2.10.004
The editor needs fixing now to take notice
of the error detail returned.
The only error in tokenising that's currently
used is if the tokenised line length
exceeds 510 bytes. Note, the length of
the tokenised line, not the length of the
ASCII line.
So we need to add an overflow message
and tokeniser failure. Not so simple as we
need a new message in the editor config
file (plenty of empty ones) but that means
we also need a program to update the
editor config file in-situ without losing the
user's current settings...
Ongoing.

Ref 1.06 The AMOS(Pro) editor can't handle numbers that won't fit in 32 bits. They are changed into a lower number. Examples: %111111111111111111111111111111111 (33 bits) will change into 1111111111 Tested with AMOSPro V2.00 uncompiled - has the bug AMOSPro V2.00 compiled - not tested yet AMOS V1.36 uncompiled - not tested yet AMOS V1.36 compiled - not tested yet Credits * bug discovery/description by Spellcoder (Mark de Jong) on 24-sep-2007 http://www.amigacoding.com/index.php?title=AMOS:Bug_Large_numbers_in_editor&oldid=217 Cause When the length exceeds 32 digits, a branch to the wrong label causes the code to continue in the middle of a decimal conversion routine. This gives a garbage result and flags it as okay. Solution Branch destination label corrected. Not the full solution! The Editor's tokeniser ignores the detail in the reply from the evaluation routine: >0 Evaluation overflow (the one we're interested in) 0 OK, we got a number <0 Not a number So it skips the set of digits that it's just tried to evaluate and carries on as if nothing was wrong! This applies to ALL numeric formats for integers. For example $123456789 would overflow and fail too. Marked as In Progress by bruceuncle +ILib.s +Lib.s V2.10.002 V2.10.004 The editor needs fixing now to take notice of the error detail returned. The only error in tokenising that's currently used is if the tokenised line length exceeds 510 bytes. Note, the length of the tokenised line, not the length of the ASCII line. So we need to add an overflow message and tokeniser failure. Not so simple as we need a new message in the editor config file (plenty of empty ones) but that means we also need a program to update the editor config file in-situ without losing the user's current settings... Ongoing.

john added the

AMOS Pro Bugs List

label 2023-03-25 15:36:51 +00:00

Sign in to join this conversation.

No Label

AMOS Pro Bugs List

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: TheIndustriousRabbit/amos-professional#4