rand() will be infrequent < 10 (at least ten in 2^15 times, if not exponentially more), so automated tests are likely to pass. If they don’t, they’re likely to pass on the second try, and then everyone shrugs and continues. If it’s buried in 500 other lines, then it’s likely the code reviewer will give it all a quick scan and say “it’s fine”. It’s the three line diffs that get lots of scrutiny.
In other words, you seem to have a lot more faith in the process than I do.
If it’s a 16-bit integer platform, it might hit every once in a while.
If it’s a 32-bit integer platform, it’ll hit very rarely.
If it’s a 64-bit integer platform, someone would have to do the math with some reasonable assumptions, but I wouldn’t be surprised if it would never hit before the universe becomes nothing but black holes.
The point being made is that it also depends how often the ‘true’ value gets used in the code. Tests might only evaluate it a few times per run, or they could cause billions of evaluations per run. You can’t know the probability of a test failure without knowing the occurrence rate of that expression.
Yes you’re correct, this was the point I was making.
To elaborate: could be 100s of times in a codebase, even 1000s, being executed in tests on local machines and build servers 100s of times a day, etc. etc.
But it would hit a different place every time… Most developers wouldn’t even consider checking for this, and the chance of getting a repro in a debugger is slim to none
This wouldn’t pass PR review and automated tests, unless they were a senior dev and used elevated privileges to mess with things behind the scenes.
It’s bold to assume those exist. Maybe there’s a reason the coworker left
Can confirm, just left a team that had 3 people for 4 pieces of legacy software and still used subversion
SVN has legit use cases still though. Git LFS is not or just barely supported in a lot of industries.
rand()
will be infrequent< 10
(at least ten in 2^15 times, if not exponentially more), so automated tests are likely to pass. If they don’t, they’re likely to pass on the second try, and then everyone shrugs and continues. If it’s buried in 500 other lines, then it’s likely the code reviewer will give it all a quick scan and say “it’s fine”. It’s the three line diffs that get lots of scrutiny.In other words, you seem to have a lot more faith in the process than I do.
rand will be called every time true is used, which could be hundreds of times for all we know
If it’s a 16-bit integer platform, it might hit every once in a while.
If it’s a 32-bit integer platform, it’ll hit very rarely.
If it’s a 64-bit integer platform, someone would have to do the math with some reasonable assumptions, but I wouldn’t be surprised if it would never hit before the universe becomes nothing but black holes.
The point being made is that it also depends how often the ‘true’ value gets used in the code. Tests might only evaluate it a few times per run, or they could cause billions of evaluations per run. You can’t know the probability of a test failure without knowing the occurrence rate of that expression.
Yes you’re correct, this was the point I was making.
To elaborate: could be 100s of times in a codebase, even 1000s, being executed in tests on local machines and build servers 100s of times a day, etc. etc.
But it would hit a different place every time… Most developers wouldn’t even consider checking for this, and the chance of getting a repro in a debugger is slim to none
Write a 5 line PR and receive 5 comments. Write a 500 line PR and receive no comments.
lgtm
Attn: security team
Hi,
I think someone on Lemmy has hacked into every work environment I’ve ever coded in
It works on my machine, most of the time.