mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Recently it looks like the method changed where mIRC now does interval*1000 if you don't use -m or -h and use that as millisecond anyway. Unfortunately the check on the parameter is now incorrect, it allows the value to overflow, triggering the command immediately:

Quote:
//timertest 1 2147483 echo -a ok | timers
* Timer test 1 time(s) 2147483000ms delay echo -a ok

//timertest 1 2147484 echo -a ok | timers
* Timer test 1 time(s) -2147483296ms delay echo -a ok
-
ok
-
where 2147484*1000=2147484000 which exceeds the maximum value of an int 32bits (2147483647).

Last edited by Wims; 10/10/13 05:47 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
This was an intentional change and is by design. This particular change was made to ensure that timers are triggered correctly, which is something that had been requested many times. The overflow issue is common to most scripting features if a very large number is specified. To get around it, you will need to specify a lower value that triggers the timer more regularly.

Joined: Jun 2012
Posts: 14
Y
Pikka bird
Offline
Pikka bird
Y
Joined: Jun 2012
Posts: 14
Correct me if I'm wrong, but it looks like you've responded to Wims as if he were reporting two separate issues with /timer: negative values and large values. If so, that is not the case.

In addition to the examples provided in the original post:

Quote:
;Specifying a large interval triggers instantly:
/timertest 1 2147483647 noop
* Timer test activated
* Timer test halted

;Specifying a *larger* interval produces an error:
/timertest 1 2147483648 noop
* /timertest: invalid parameters


Since the interval gets multiplied *1000 internally (2147484 == 2147484000ms), it appears the error check is simply off by an order of 1000. No error is produced between ~2147484-2147483647, but the integer overflows and creates a negative timer which triggers instantly.

Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Bump, the issue was not fixed.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I compared the current version to mIRC v6.35, which is the baseline comparison for the v7.x series, and it seems to behave in the same way.

The /timer command checks the delay value when the command is called and halts the script at that point if it overflows. However, if the value overflows later on during millisecond calculations, it triggers the timer immediately and stops it.

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.

Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Well, it looks like I thought the change with the millisecond usage was causing the issue but indeed it behaves the same on 6.35.

But that doesn't really change the original intention of my report: wasn't it intended for /timer to use a 32bits signed int for the delay value? Why is the value 2147483647 overflowing in the first place?
I made the report because I believe a value of 2147483647 should be used as it is without overflowing. Why allow 2147483647 if it's not going to be used as it is? Was it an oversight when implemented?
It all really depends on what was intended in the first place but the behavior makes little sense to me.
Quote:
I could change this so that /timer checks for values larger than 2147483 and halts the script with an error immediately
Naturally, since the current behavior makes little sense to me, this change also doesn't really make sense, why is the value 2147483 unacceptable here?
Any change at this point would break scripts, but allowing the value to contain number up to 32bits signed int (which is what I propose) would only cause scripts who were not expecting a 32bit signed int to be used, to break. I believe my proposal would break far more less script.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jun 2012
Posts: 14
Y
Pikka bird
Offline
Pikka bird
Y
Joined: Jun 2012
Posts: 14
Originally Posted By: Khaled

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).

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
A script that relies on a buffer overflow to trigger seems a bit strange.

Thanks for your comments. Scripters often depend on aspects of the scripting language that I never anticipated. Any changes that break even a small number of scripts accumulate and gradually break more scripts over time. In addition, many scripts are used by users who would not know how fix them. So one of my priorities is not to make such changes and to maintain backwards compatibility as much as possible. A behaviour that has been in place for so long that it is essentially part of the scripting language is normally left in place unless it has serious consequences.


Link Copied to Clipboard