Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

setBigTimeout

evanhahn.com

Post reply on HN
Print view View original

111–120 of 129 posts

Re: setBigTimeout

#111

Post by purplesyringa »

Interestingly, this library seems to suffer from the opposite problem: where setTimeout can trigger earlier than expected, setBigTimeout can trigger never at all!

The problem is that when setBigTimeout is invoked with a floating-point number (and numbers are floating-point in JS by default), it keeps computing the time left till trigger in floating point. But FP numbers are weird:

    > 1e16 - 1 == 1e16
    true
At some point, they don't have enough precision to represent exact differences, so they start rounding, and this gets extremely more inaccurate as the value increases. For correct behavior, remainingDelay needs to be stored in BigInt.

Of course, this problem is mostly theoretical, as it starts happening at around 2^83 milliseconds, which doesn't even fit in a 64-bit time_t, and it's not like humanity will exist by then. But still!

Re: setBigTimeout

#112

Post by paulddraper »

purplesyringa wrote: post #111

Interestingly, this library seems to suffer from the opposite problem: where setTimeout can trigger earlier than expected, setBigTimeout can trigger never at all! The problem is that when setBigTimeout is invoked with a floating-point number (and numbers are floating-point in JS by default), it keeps computing the time left till trigger in floating point. But FP numbers are weird: > 1e16 - 1 == 1e16 true At some poin…

I would go so far as to say entirely theoretical.

Re: setBigTimeout

#113

Post by paulddraper »

swatcoder wrote: post #31
n2d4 wrote: post #10

The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected: const attackerControlled = ...; if (attackerControlled { console.log("Surely at least 1min has passed!"); }, attackerControlled); The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better so…

That's just terrible input validation and has nothing to do with setTimeout. If your code would misbehave outside a certain range of values and you're input might span a larger range, you should be checking your input against the range that's valid . Your sample code simply doesn't do that, and that's why there's a bug. That the bug happens to involve a timer is irrelevant.

> If your code would misbehave outside a certain range of values and you're input might span a larger range, you should be checking your input against the range that's valid.

What's funny is you think that about the caller of setTimeout but not setTimeout itself :)

Re: setBigTimeout

#114

Post by balls187 »

ashkankiani wrote: post #73
swatcoder wrote: post #31

Earlier quoted context omitted.

That's just terrible input validation and has nothing to do with setTimeout. If your code would misbehave outside a certain range of values and you're input might span a larger range, you should be checking your input against the range that's valid . Your sample code simply doesn't do that, and that's why there's a bug. That the bug happens to involve a timer is irrelevant.

You are a bad programmer if you think silently doing the wrong thing is not a bug. The right thing to do with unexpected input as the setTimeout library author is to raise an exception.

The wrong thing, or the undefined thing?

Feel free to make a proposal to ECMA.

Re: setBigTimeout

#115

Post by sehugg »

ipython wrote: post #83

Sounds a lot like the famous windows 95 bug when it would crash after 49.7 days of uptime [1] [1] https://news.ycombinator.com/item?id=28340101

GetTickCount() still exists and still returns a DWORD.

Re: setBigTimeout

#116

Post by chacham15 »

arghwhat wrote: post #13
n2d4 wrote: post #10

The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected: const attackerControlled = ...; if (attackerControlled { console.log("Surely at least 1min has passed!"); }, attackerControlled); The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better so…

A scenario where an attacker can control a timeout where having the callback run sooner than one minute later would lead to security failures, but having it set to run days later is perfectly fine and so no upper bound check is required seems… quite a constructed edge case. The problem here is having an attacker control a security sensitive timer in the first place.

I would imagine the intent behind this would be that the attacker has indirect control over the timeout. E.g. a check password input which delays you in between attempts doubling the length of time you have to wait in between each failed attempt. With this bug in place, the attacker would simply wait all the timeouts until the timeout exceeded 25 days at which point they could brute force the password check back to back.

Re: setBigTimeout

#117

Post by ajkjk »

Klonoar wrote: post #106
ajkjk wrote: post #74

Earlier quoted context omitted.

What? Of course it's a Sourcehut problem. They chose to use that word and could choose to use a better one.

Tree has been used for this kind of thing for decades now.

So what? There are still better words for it.

Re: setBigTimeout

#118

Post by rzz3 »

Awesome! Already have a project I can use this on, thanks.

As a side note, why do you use this weird non-Github, non-Gitlab, non-Bitbucket sketchy looking git host? I can see the code obviously, but it makes me worry about supply chain security.

Re: setBigTimeout

#119

Post by malthejorgensen »

rzz3 wrote: post #118

Awesome! Already have a project I can use this on, thanks. As a side note, why do you use this weird non-Github, non-Gitlab, non-Bitbucket sketchy looking git host? I can see the code obviously, but it makes me worry about supply chain security.

sourcehut isn’t weird at all.

It’s made by Drew Devault who is mostly well-respected in the hacker community, and it’s made exactly to be an alternative to BigCo-owned source hosts like GitHub, Gitlab and Bitbucket.

Re: setBigTimeout

#120

Post by ericyd »

yifanl wrote: post #7

If we're pedantic, this doesn't actually do what's advertised, this would be waiting X timeouts worth of event cycles rather than just the one for a true Big timeout, assuming the precision matters when you're stalling a function for 40 days.

I don't understand how an implementation detail means it isn't doing what is advertised?
Post reply on HN