ListView sorting broken with numbers >32-bits

[Synetech]

ListView sorting doesn't work if the numbers in the list are bigger than 32-bits, the results look random (though probably just appear random but are correct for the first 32-bits of the numbers).

[just me]

Did you try it with AHK 64-bit?

Edit:

Integer: For sorting purposes, indicates that this column contains integers. To be sorted properly, each integer must be 32-bit; that is, within the range -2147483648 to 2147483647. If any of the values are not integers, they will be considered zero when sorting (unless they start with a number, in which case that number is used). Numbers may appear in either decimal or hexadecimal format (e.g. 0xF9E0).

LV_ModifyCol

[lexikos]

Evidently it is unsupported, not a bug.

Ordering of items considered "equal" (such as all being considered zero) by the qsort algorithm generally seems arbitrary. They are supposed to be equal, so it should not matter what order they are placed in.

[Synetech]

Did you try it with AHK 64-bit?

Edit:

Integer: To be sorted properly, each integer must be 32-bit; that is, within the range -2147483648 to 2147483647. If any of the values are not integers, they will be considered zero when sorting (unless they start with a number, in which case that number is used).
LV_ModifyCol

Yes, I tried it with 64-bit AHK. It's strange because of the three columns, one looks like it's correct, but the other two are just strange results. It's odd that even the 64-bit version is limited to 32-bit, especially since even 32-bit programs are capable of handling 64-bit numbers.