Yep, it's a bug in the compiler. It's related to a bug in the ValRout() function in the AMOS core library. That function evaluates a numeric string and returns an integer, single or double. It returns a zero and a fail flag if anything goes wrong (overflow or 'bad' number) or if the string is not a number.
The function is used for two tasks:
1: By the tokeniser in the editor to convert what's been typed in into a number token.
2: By the AMOS Basic Val() function.
The ValRout() function has minor bugs in a branch to the wrong label and inconsistent return values. Unfortunately, the function and parts of it were copied and pasted (complete with bug!) to other parts of the sources, including the compiler. Tracking down what calls the function was not straightforward as at least one reference is via a JSR(An).
Anyway, the function also takes a param in a data register (typing on my phone, so sorry about lack of specifics) which indicates whether to include the sign or not. Reason being that the tokeniser will already have parsed and created a token for any sign, so all it wants is the digits. Whereas the Val() function will need the full signed result.
So it looks like you've found a new bug where the compiler isn't setting the 'sign required' param.
V2.10 is still being worked on. I had a major, major back operation last year which I'm still recovering from. So it's been a bit slow going...
Author
Topic: AMOS Pro V2.10 alpha release (Read 49237 times)