"The help file is incorrect until it documents the behaviour."
Again, no. The help file may lack details, but the statement "Returns A binary AND B" is not incorrect on its own. It doesn't state that this will work for any number, and it would be just as incorrect to assume that it would, especially within the context of mIRC (a language where you should already know of and expect many size/functional limitations). And funny enough, mIRC doesn't even say A and B should be numbers, or even that they should be base 10. Hey, maybe we should complain that mIRC doesn't accept $and(0A, 0A) as valid input. I mean, under MY assumptions that should work, therefore the helpfile is wrong-- right?
But this is all pointless semantics and completely besides the point. The help file is not a spec for behaviour, it's merely a pointer. It's not meant to enumerate every detail, although that would be nice. If you can't deal with this and still want to call the help file "incorrect", go ahead, but I don't see what that changes.
As far as the "wrapping" is concerned, you're making implementation assumptions. Who says mIRC integer overflow is involved here? How do you know its not truncation? Again, the behaviour is defined by.. the behaviour. That's how it works. If you want, you can think of the help file as saying: "takes the binary AND of A and B. If A or B are greater or equal to 2^32 the result is undefined."-- Happy now?
If you're not, make a feature suggestion to extend the behaviour to 64-bit integers on the Feature Suggestion forum. Complaining about it here is completely unproductive.
