Forth allows certain base-setting prefixes in literals:
e.g.,:
& – decimal
# – decimal
% – binary
$ – hexadecimal
unfortunately, it seems that in swapforth the error in parsing of the literal after the prefix leaves the base modified according to the prefix. Below is an example of session demonstrating the issue:
>decimal
ok
>%101 .
5 ok
>$32 .
50 ok
>%fggdg
error: F3 +
ok
>$32 .
110010 ok
>
In gforth, an attempt to parse the incorrect literal doesn't lead to changed base:
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
decimal ok
%101 . 5 ok
$2 . 2 ok
$32 . 50 ok
%fggdg
:5: Undefined word
>>>%fggdg<<<
Backtrace:
$7F0C14C6EA68 throw
$7F0C14C84DB0 no.extensions
$7F0C14C6ED28 interpreter-notfound1
$32 . 50 ok
Similar problem in swapforth occurs also for other base-setting prefixes. Below is an example of unintended switching to hex mode due to entering the incorrect literal with "$" prefix:
>decimal
ok
>$fgdds
error: F3 +
ok
>$32 .
32 ok
>#51
ok
>.
33 ok
Forth allows certain base-setting prefixes in literals: e.g.,:
unfortunately, it seems that in swapforth the error in parsing of the literal after the prefix leaves the base modified according to the prefix. Below is an example of session demonstrating the issue:
In gforth, an attempt to parse the incorrect literal doesn't lead to changed base:
Similar problem in swapforth occurs also for other base-setting prefixes. Below is an example of unintended switching to hex mode due to entering the incorrect literal with "$" prefix: