1) Procedure HexValue in M3CLex was accepting any letter as a hex digit. For a LONGINT based literal, the 'L' was treated as a hex digit that was out of range, leading to an error message. This affected INTEGER based literals too, but it probably rarely/never happened. 2) With that fixed, scanning of a based LONGINT literal ignored the 'L'. 3) Scanning of an unbased LONGINT literal was detecting the 'L' and setting the literal type to LONGINT, but didn't put the 'L' in to the accumulated string for the literal. 4) Those exposed that TextTo.Longint in M3CBackEnd_C did not count the 'L' as used, generating another error.
Also: 5) Renamed some variables from "l" to "len". In my editor font, letter 'l' and digit '1' are indistinguishable without resorting to xmag, leading to things like: "IF l>1". 6) Added acceptance of capital 'X' as a flag for hex escape sequences in character and text literals. (detail)
More fixes for problems with LONGINT based literals in m3tk:
1) Procedure HexValue in M3CLex was accepting any letter as a hex digit. For a LONGINT based literal, the 'L' was treated as a hex digit that was out of range, leading to an error message. This affected INTEGER based literals too, but it probably rarely/never happened. 2) With that fixed, scanning of a based LONGINT literal ignored the 'L'. 3) Scanning of an unbased LONGINT literal was detecting the 'L' and setting the literal type to LONGINT, but didn't put the 'L' into the accumulated string for the literal. 4) Those exposed that TextTo.Longint in M3CBackEnd_C did not count the 'L' as used, generating another error.
Also: 5) Renamed some variables from "l" to "len". In my editor font, letter 'l' and digit '1' are indistinguishable without resorting to xmag, leading to things like: "IF l>1". 6) Added acceptance of capital 'X' as a flag for hex escape sequences in character and text literals. (detail)
![[fingerprint]](/static/31949961/images/16x16/fingerprint.gif)
