I could change this so that /timer checks for values larger than 2147483 and halts the script with an error immediately, however this would break all existing scripts that use larger values, expecting the script not to be halted, and for the timer to be triggered.
A script that relies on a buffer overflow to trigger seems a bit strange. I would expect those cases to be in the minority compared to situations where a programmer expected a large value to wait rather than being triggered immediately. If there are indeed any scripts that rely on values in that particular undocumented range to be triggered immediately, then they need only update to use a 0 or negative value instead. A change here might actually fix more scripts than it breaks.
I think the case to worry about are the ones where programmers weren't aware of the behavior of large numbers and were also unaware that their timers were executing immediately. By changing the error check, those scripts would start producing errors rather than executing the timers immediately. In those cases it would appear that mIRC was at fault even though those scripts weren't behaving "correctly" in the first place.
If it's not possible to change mIRC to allow timers that wait longer than 2147483 seconds then my suggestion would be to make anything between 2147483-2147483648 display a warning (but maybe not a halting error?). I might have also suggested that any value larger than the actual maximum also be reduced to the maximum wait time, but I worry that because the maximum time is only ~3 weeks that scripts would again silently be executing too soon (but in an even less obvious way to programmers).
