Bug? Change of long hex literal processing

OliverA

Expert
Licensed User
Longtime User
I encountered the same issue as @Robert Valentino (https://www.b4x.com/android/forum/threads/bug-11-20-long-literal.137026/#content). Code that worked on B4J 8.90
B4X:
	Public Const MAX_32IN64 As Long = 0x000000007FFFFFFFL
	Public Const MIN_32IN64 As Long = 0xFFFFFFFF80000000L
now throws an error during compiling with B4J 9.80
Public Const MAX_32IN64 As Long = 0x000000007FFFF
src\xxx.java:445: error: ')' expected
_max_32in64 = ((long)0x000000007ffffffflL);
I found a post from @Erel where he mentions that "There is no L suffix in B4X" (https://www.b4x.com/android/forum/threads/bug-converting-string-to-long.133584/post-844424), but the above code has been working for me on all 3 platforms (B4A, B4i, and B4J). It's not a huge deal, but still interesting that a feature worked that should not have existed and now does not work anymore. I think the break in usage occurred with the official support of long hex literals (B4J 9.30, B4A 11.20, and B4i 7.80).

I'm not expecting any future changes in B4X in regards to this issue. I'm just posting in case anyone else runs into this (besides myself and @Robert Valentino). The fix is easy (remove the L).
 

OliverA

Expert
Licensed User
Longtime User
Update: In v 8.90 you actually HAD to use the L, otherwise you would get the following error message:
Public Const MIN_32IN64 As Long = 0xFFFFFFFF80000
src\xxx:448: error: integer number too large
_min_32in64 = (long) (0xffffffff80000000);
Therefore, the L suffix must have been an integral part of B4X (at least when it comes to hex literals).
 
Top