Forums Bug Reports timer bug

an simple example .. my systemclock show '09:00' .. when I start a timer like '/timer1 08:59 1 0 echo -s just a test' it will be executed.

I dont know if it is a known bug (sorry if it is)

BUG!!!
Verified w/ 6.03 winnt4

yup it executes for me using winXP mirc 6.03 ... id say its a bug of some sort ..... i dont know why when the system clock is one minute ahead of the time u set the timer for that it would execute.

weird, worked for me fine on win95b - when the system clock changed, it executed

Executes for me (WinXP Professional Edition, mIRC 6.03).

Don't want to be patronising or anything, but make sure you only make the timer execute 1 minute before the time in your system tray (for example, if it says 13:21 then do /timer1 13:20 blah blah). Make sure you got v6.03 too...

Otherwise, weird if it's affected by Windows OS....I'm going to complain to Bill!

Regards,

Interesting.

If I had to make a guess, I'd say because Timers are slightly inaccurate (slow), that Khaled leaves a window of tolerence in case the timer fires late or has to wait for a script to finish (eg, $findfile).

So, it's probably saying "Hmm, I was suppose to fire at 8:59 and it's 9:00 already... POOP, I'm late!"

- Raccoon

You really shure it using that "POOP" sound?

good point ..... but could this also be something in the reasoning behind the 49 day limit too? i guess only khaled himself can explain this one

Oh, that one's easy.

Internally, mIRC uses 32bit (Long) intergers to store the timer's delay and repetitions.

2^32 == 4294967296, that is the greatest value a 32bit unsigned long can store.

Since you can specify a duration in milliseconds with -m, mIRC simply converts and stores all timer durations in milliseconds.

4294967296 / 24 / 60 / 60 / 1000 == 49days 17hrs 2mins 48secs 296ms

- Raccoon

yup - I see what you mean now. Misunderstood before but did as you stated and it fired off

I don't know if the Borland compiler supports it, I know MSVC++ does, it has a type called _int64 (64bit integer). The Windows headers have a type called LONGLONG (which is also 64bit). Using that for the timer information would solve that problem. That datatype isn't exactly standard, a 64bit integer is standard in C, but not in C++. However I've yet to find a compiler that prohibits its use in C++, so as long as Khaled doesn't care whether mIRC compiles on _every_ standard compiler, it should solve the problem.

Agreed.

I never suggested there wasn't a solution, though I'd ask if a "solution" is necessary for this "bug".

My concern with using a 64bit int in the /timer code in a 32bit environment, is the extra few but collective cycles spent in accessing the variable... all for the 1 in a million chance someone needs a 50 day duration.

I think Khaled should first worry about bringing the rest of mIRC up to 32bit from 16bit. (eg, 64K limits, Line Too Long, etc)

- Raccoon

Yeah, doing 64bit arithmetic in a 32bit environment is slower. But Khaled could probably implement it in such a way that it only uses a 64bit integer if it is needed. Meaning use 32bit by default, use 64bit if 32bit is too small.

2^32 - 1 = 4294967295, that is the greatest value a 32bit unsigned long can store