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
No, you can’t assume that. The probability of hitting the condition each time is low. If there aren’t very many calls that hit this, it could easily slip through. Especially on 64-bit int platforms.
Yes agree if you’re talking about unit tests. I’m thinking smoke tests, which is are the most common automated tests in games, where I’ve spent most of professional career. The amount of booleans checks that happen in a single frame I doubt the game wouldn’t crash within the first couple seconds.
I hope I learn some day how to code a bug in python that will not show up in any error messages and absolutely ruins a program. I’d love to find a random program at whatever job I end up at and before quitting just ruin it with a random line of code that doesn’t output an error code.
It’s not hard to do. What would be hard would be getting it through code review. Like the example provided… how would that ever get through code review for a merge? Must not be a well-protected code base?
Publish your own package to PyPI that on import does some evil stuff. Name the package something similar to a known, but not too well known package. Supply chain attacks are even less defended against than other stuff.
All this relies on companies being shit though, but well, we all know that’s the case in a lot of places.
Yea… pipeline and dependency auditing isn’t trivial if you want to catch the subtle stuff. Even most of the devs that know how to do it are going to respond with, “above my pay grade…” unless they’re somehow actually getting paid enough to be arsed to do it correctly…
Logical errors are an entire domain of programmer troubleshooting. All you’ll have to do is attempt to learn programming, and you WILL write something that throws no errors, performs terribly, and confuses you for hours.
We all do. It’s almost a badge of honor to push past a few of them.
Hell, sometimes it happens when no one has made an error but a particular mix of data or odd arrangement of hardware it ends up running on hits an undiscovered edge case that buggers things up.
What the hell? Thats not funny or anything it just fucks with your ex-coworkers who probably werent the problem, management isnt affected by that.
Pro tip, you seem really arrogant these days and you need to tone that down before you enter the industry. Its nothing to be ashamed of and I’m not trying to insult you, you just assume your experiences are way more universally valid than they are.
I don’t think that will have the impact people think it will, maybe at first, but eventually it’ll just start treating “wrong” code as a negative and reference it as a “how NOT to do things” lmao
For sure, but just like that whole “poison our pictures” from artists thing, the people building these models (be it a company or researchers or even hobbyists) are going to start modifying the training process so that the AI model can recognize bad code. And that’s assuming it doesn’t already, I think without that capability from the getgo the current models would be a lot worse at what they generate than they are as is lmao
That exact version will end up making “true” false any time it appears on a line number that is divisible by 10.
During the compilation, “true” would be replaced by that statement and within the statement, “LINE” would be replaced by the line number of the current line. So at runtime, you end up witb the line number modulo 10 (%10). In C, something is true if its value is not 0. So for e.g., lines 4, 17, 116, 39, it ends up being true. For line numbers that can be divided by 10, the result is zero, and thus false.
In reality the compiler would optimise that modulo operation away and pre-calculate the result during compilation.
The original version constantly behaves differently at runtime, this version would always give the same result… Unless you change any line and recompile.
The original version is also super likely to be actually true. This version would be false very often. You could reduce the likelihood by increasing the 10, but you can’t make it too high or it will never be triggered.
One downside compared to the original version is that the value of “true” can be 10 different things (anything between 0 and 9), so you would get a lot more weird behaviour since “1 == true” would not always be true.
If the error is too frequent it will be hunted down very fast, what you want is errors that happen no more than once every month, maybe add another level that ensures this only triggers based on the running time.
That is true, but from a human perspective it can still seem non-deterministic! The behaviour of the program as a whole will be deterministic, if all inputs are always the same, in the same order, and without multithreading. On the other hand, a specific function call that is executed multiple times with the same input may occasionally give a different result.
Most programs also have input that changes between executions. Hence you may get the same input record, but at a different place in the execution. Thus you can get a different result for the same record as well.
__ LINE __ is a preprocessor macro. It will be replaced with the line number it is written on when the code is compiled. Macros aren’t processed when debugging. So the code will be skipped during debug but appear in the compiled program, meaning the program will work fine during debug but occasionally not work after compile.
“__ LINE __ % 10” returns 0 if the line number is divisible by 10 and non-zero if not. 0 is considered false and non-zero is considered true.
#define is also macro. In this case, it will replace all instances of “true” with something that will only sometimes evaluate to true when the program is compiled.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.