863
top 50 comments
sorted by: hot top controversial new old
[-] perviouslyiner@lemmy.world 241 points 9 months ago* (last edited 9 months ago)

define it as ( __LINE__ % 10) so that the problem goes away when you add a debug statement

[-] CodexArcanum@lemmy.world 80 points 9 months ago

Makes the error a little too frequent, but does obscure any performance penalty and is some truly evil genius work!

[-] perviouslyiner@lemmy.world 84 points 9 months ago
[-] jettrscga@lemmy.world 61 points 9 months ago* (last edited 9 months ago)

Full version

Edit: from XKCD

load more comments (1 replies)
[-] Prunebutt@slrpnk.net 41 points 9 months ago

Can someone ELI5 what this does?

[-] yggdar@lemmy.world 85 points 9 months ago* (last edited 9 months ago)

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)
[-] BananaOnionJuice@lemmy.dbzer0.com 39 points 9 months ago

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.

[-] BaumGeist@lemmy.ml 7 points 9 months ago

The original version constantly behaves differently at runtime

It actually doesn't, since rand() is deterministic.

When no seed value is specified, rand() is automatically seeded with 1 at the initial call within any program It then uses the previous output as seed for the next, so it will always have the same output sequence

load more comments (1 replies)
[-] tunawasherepoo@iusearchlinux.fyi 29 points 9 months ago

__LINE__ returns the line of code its on, and % 10 means "remainder 10." Examples:

1 % 10 == 1
...
8 % 10 == 8
9 % 10 == 9
10 % 10 == 0 <-- loops back to 0
11 % 10 == 1
12 % 10 == 2
...
19 % 10 == 9
20 % 10 == 0
21 % 10 == 1

In code, 0 means false and 1 (and 2, 3, 4, ...) means true.

So, if on line 10, you say:

int dont_delete_database = true;

then it will expand to:

int dont_delete_database = ( 10 % 10 );
// 10 % 10 == 0 which means false
// database dies...

if you add a line before it, so that the code moves to line 11, then suddenly it works:

// THIS COMMENT PREVENTS DATABASE FROM DYING
int dont_delete_database = ( 11 % 10 );
// 11 % 10 == 1, which means true
[-] BaumGeist@lemmy.ml 18 points 9 months ago

A lot of these replies have high hopes for 5 year olds

[-] ImplyingImplications@lemmy.ca 14 points 9 months ago* (last edited 9 months ago)

__ 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.

load more comments (1 replies)
[-] IphtashuFitz@lemmy.world 17 points 9 months ago

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…

[-] perviouslyiner@lemmy.world 10 points 9 months ago

only when your coordinates were within a train depot in Poland?

https://www.youtube.com/watch?v=XrlrbfGZo2k

load more comments (4 replies)
[-] SkyNTP@lemmy.ml 116 points 9 months ago

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.

[-] maynarkh@feddit.nl 175 points 9 months ago

It's bold to assume those exist. Maybe there's a reason the coworker left

[-] frezik@midwest.social 113 points 9 months ago

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.

[-] killeronthecorner@lemmy.world 27 points 9 months ago

rand will be called every time true is used, which could be hundreds of times for all we know

[-] frezik@midwest.social 25 points 9 months ago

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.

[-] Morphit@feddit.uk 12 points 9 months ago

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.

load more comments (2 replies)
[-] steal_your_face@lemmy.ml 62 points 9 months ago* (last edited 9 months ago)

Write a 5 line PR and receive 5 comments. Write a 500 line PR and receive no comments.

[-] grandkaiser@lemmy.world 10 points 9 months ago

Attn: security team

Hi,

I think someone on Lemmy has hacked into every work environment I've ever coded in

load more comments (1 replies)
[-] PrettyFlyForAFatGuy@lemmy.ml 16 points 9 months ago

you'd be surprised what slips through review

load more comments (3 replies)
[-] victorz@lemmy.world 58 points 9 months ago

Funny but I call bullshit all day

load more comments (2 replies)
[-] Thcdenton@lemmy.world 54 points 9 months ago* (last edited 9 months ago)

That happened 🙄

[-] mvirts@lemmy.world 27 points 9 months ago

Lol I don't think the preprocessor would be too happy with a space after #

[-] nabladabla@sopuli.xyz 19 points 9 months ago

C preprocessor wouldn't care about it

load more comments (1 replies)
[-] Awkwardparticle@programming.dev 15 points 9 months ago

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.

load more comments (1 replies)
[-] EmperorHenry@discuss.tchncs.de 6 points 9 months ago

Is this some simple line of code that just shuffles everything around in file storage areas?

[-] lhamil64@programming.dev 43 points 9 months ago

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"

load more comments (2 replies)
load more comments
view more: next ›
this post was submitted on 09 Feb 2024
863 points (97.6% liked)

Programmer Humor

19623 readers
1 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS