define it as ( __LINE__ % 10) so that the problem goes away when you add a debug statement
Makes the error a little too frequent, but does obscure any performance penalty and is some truly evil genius work!
Full version
Edit: from XKCD
Can someone ELI5 what this does?
deleted by creator
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.
A slightly more consistent version would be
((__LINE__ % 10) > 0)deleted by creator
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.
Decades ago I had to debug a random crash. It only happened on Wednesdays. On Wednesdays in September. On Wednesdays in September after the 10th…
I kinda want to hear more of this story… care to share the details? i.e. what was the root cause?
It was pure c code that was used to print reports, and included the date in a header. Whoever wrote it miscalculated the size of the buffer for the header by one byte. When the date was the longest month & day spelled out plus a two digit day of the month then it would overflow the buffer, resulting in the program crashing.
That’s very funny.
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
Write a 5 line PR and receive 5 comments. Write a 500 line PR and receive no comments.
It works on my machine, most of the time.
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.
you’d be surprised what slips through review
A lot of you have a lot of faith in people reviewing PRs. I know a few Sr. developers, that if shit was too busy, would skim it and say 'fuck it, it will be QAs problem. If you put this in the correct sub-system in file that would only be executed once a month, for example a maintenance class, It would be really hard to notice something is wrong if it didn’t cause issues seen immediately. Maybe this is the story of an intern that added something that also fucked up boolean comparisons in a subsystem used once a month. Where there is a 2 week lag between the execution and operations noticing something wrong.
{devs} would skim it and say 'fuck it, it will be QAs problem.
And then delays until code complete would eat up all of QA’s time so they have no real time left to test before app release into production.
deleted by creator
Lol I don’t think the preprocessor would be too happy with a space after #
C preprocessor wouldn’t care about it
Funny but I call bullshit all day
Yeah, how did they commit this to anywhere that would hurt?
They did not ✌️
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.
deleted by creator
This looks like a C macro. Basically what it does is replaces the word “true” in the code with (rand() > 10). The rand() function will return a random number from 0 to 32767. So (rand() > 10) will very likely return “true” but not always.
So say you have some code like this: if (someVar == true) { // Do stuff } It would replace “true” with code that usually evaluates to “true” but not always. So every so often your code would just do the wrong thing but it would be hard to debug because it would be rare.
Granted, in that example you probably would just write “if (someVar)” making this moot, but there are more realistic cases where you’d use the constant “true”
