Tokenising bug v1.11.13 ZXOS_2.09 (integers in expressions inside sprite commands become floats)

[NealeTools]

Repro code:

100 SPRITE PRINT 1: SPRITE BORDER %1
9120 FOR %i=%1 TO %3: READ %b[i]: NEXT %i: %c[s]=%12
9122 SPRITE %s,%b[1]<<4+(b[3]=3)-(b[3]=15),%b[2]<<4+(b[3]=1)-(b[3]=13),%63,%b[3],%0,%0,%0: %s=%s+1
9125 PAUSE %0

9260 DATA %3,%4,%1

Run gives nonsense in basic 9122. I have tracked it down to the -(b[3]=13).
If I change "13" for another number, it works fine. If I simply edit and re-enter the line inside NextBASIC (without making any changes, it also fixes itself.

If I change the -(b[3]=13) to -(b[3]=(13)) it still gives nonsense in basic.
If I change the -(b[3]=13) to -(b[3]=(11+2)) it runs fine.

[NealeTools]

Minimal version:

100 SPRITE PRINT %1: SPRITE BORDER %1
9122 SPRITE %s,,%b=13,,%1
9125 PAUSE %0

Strangely, this one doesn't give an error, but the sprite is not printed. However, editing the line in ZXOS editor, allows the sprite to be visible when run again.
The errors still seems specific to the value "13".

[NealeTools]

Interesting, so a hex comparison (of the exported tokenised version) reveals that 12 or 13 are being encoded as floats (I think - 5 bytes?). And that there is a small difference between the "12" and "13" versions.
NOTE: I had actually assumed that these were being interpreted as integers due to the leading %...

[NealeTools]

Finally, here is the corrected tokenised form (saved from ZXOS): Yes, as expected, the "13" value is encoded as an integer, not a float:

I think this means I need to be really careful in my code when using expressions inside functions (until @remy may have a chance to update). Why 12 (and other numbers) work without an error even when incorrectly tokenised as floats, remains unclear.

[remy]

Ack on this - and you're right, it's being encoded as a number and not an int. The int parsing logic (on my side) is… a little brittle at times, especially in complex statements. I'm taking a look now.