Forums Feature Suggestions Support for longer or unsigned integers

I've run into problems with mIRC not supporting long enough integers. The prime example is when using a script to store the size of sent/received DCCs in bytes. When the value gets too large, the sign flips, and you get negative values. It wouldn't be so much of a problem if the $bytes() identifier accepted input values of anything besides bytes (i.e. kilobytes, megabytes, etc...) by using another parameter, but right now I have to divide, round, then store the value, then when I want to use the $bytes() identfier for the size I need to multiply again. This also causes for a loss of precision, so support for longer intergers would be more ideal than a slight modification to the $bytes() identifier.

There are no signed or unsigned integers in mIRC, as far as it's concerned everything is a string unless it's passed to one of a few identifiers ($calc(), $bytes(), etc.). As for $bytes() not supporting large enough integers I just used $bytes() to calculate a file size of over 500TB (500,000GB), I can't believe that anyone would ever transfer anything remotely close to that size using DCC.

I believe there was a bug in $bytes where it didn't like files just in the small gigabyte range (I tested it on a ~4gb log file). This was a little while ago, but the versions.txt does not report any fixes for $bytes since v5.8 :shrug:

the bug you are talking about is in $file().size, and its still not fixed

Well, I did some more searching, and it appears to me that the problems isn't in the $bytes identifier OR the $file().size identifier. However, it appears that since I'm storing the size in a hash table it doesn't support as long of an integer/string (It must be treating is as an integer at least when it /hinc's because it's flipping the sign which is characteristic of signed integers when they get too large). Would storing the value in a variable solve the problem?

Alright, it appears it can only do 32 bit math (sigh)....X-D
It tops out at binary "11111111111111111111111111111111" which is negative, so the largest positive is "011111111111111111111111111111111", or 2.12GB, which is definately not enough for DCC tracking in bytes. I guess I'll just have to record DCC filesize stats in kilobytes. Thanks anyways!