Tokeniser: Binary Numbers larger than 32-bit Truncated or Masked #4
Labels
No Label
AMOS Pro Bugs List
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: TheIndustriousRabbit/amos-professional#4
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
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:
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.