Forums Bug Reports if '&' operator regression

It took me several years to notice, but one of my older scripts broke due to what seems to be a regression. The following code works correctly in mIRC 6.35, but not in the two mIRC 7 versions I tested (7.58 and 7.22):


These values are within the basic 32-bit range also supported by other bitwise functions ($and etc.), so I am sure the original behavior was the right one..

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.

Thank you for the elaborate reply. To be clear, though: what I am expecting is that the full unsigned 32-bit range be supported, for overall consistency with the built-in bitwise identifiers. That is a much more constrained issue to resolve than restoring any previous general overflow/underflow behavior, which at this point is no longer all that interesting I think (nobody else complained, after all). Given your explanation, I guess that is now more of a feature request than a bug report, but I still think that supporting the full unsigned 32-bit range makes sense. I have changed my script to use $isbit though, so leaving everything as is is also fine with me.

Right, ideally, it should have been working on unsigned 32-bit integers, like the bit-handling identifiers. It's an old feature but I can't see how changing it to use unsigned 32-bit integers will make any difference at this point, so this change will be in the next beta.

That sounds good, thank you!