Thanks for your bug report. I was able to reproduce this issue. The code used for "&" in newer versions of mIRC is actually identical to v6.35.
After v6.35, I upgraded to the Visual C++ 2008 compiler. This compiler handles invalid/out-of-range values differently. In older versions of Visual C++, atoi() will wrap around an overflow/underflow value and return that as a result. In newer versions of Visual C++, or at least, Visual C++ 2008, atoi() does not do that - it returns the maximum/minimum value allowed by the integer type.
There is a discussion about atoi()
on stackoverflow. The conclusion seems to be that for out-of-range values, the result is undefined behaviour, as defined by the POSIX/C99/C11 standards.
That said, I could make "&":
1) check for an atoi() overflow/underflow error and make it return 0. However, that would still break scripts like yours that expect the old overflow wrap-around behaviour.
2) use INT64 values to allow a larger range of values but this would still not be backwards compatible.
3) switch to using strtol() which should return an overflow value, like the older atoi(). However, this may be compiler-specific as some people report seeing the same behaviour as atoi(). When I update to a newer version of Visual C++, the issue may return.
4) use a custom implementation of atoi() that reproduces the overflow/underflow behaviour you are expecting. Generally something I would avoid as I prefer to use standard functions.
So, technically, your script is depending on an undefined overflow/underflow behaviour.Update:
I just tested strtol() and it behaves like atoi(). So scratch option 3.