this post was submitted on 07 Sep 2024
221 points (97.8% liked)

Programmer Humor

19503 readers
1268 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
 
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 1 points 2 months ago (1 children)

Some kind of Caesar cipher you made?

fIy uo rolevl teet rsi'n tigev nnit ehf ro mfoh gilh yboufcstadeC ,sii terlayla l vo eelttre ? Iod'n tnkwo ,ub thwtaI d onkwoi shttaI l vo eoy!u< 3%

[โ€“] [email protected] 3 points 2 months ago* (last edited 2 months ago)

Whoops! When I looked at the second time that the shift value is calculated, I wondered if it would be inverted from the first time, but for some reason I decided that it wouldn't be. But looking at it again it's clear now that (1 - i) = (-i + 1) = ((~i + 1) + 1), making bit 0 the inverse. Then I wondered why there wasn't more corruption and realized that the author's compiler must perform postfix increments and decrements immediately after the variable is used, so the initial shift is also inverted. That's why the character pairs are flipped, but they still decode correctly otherwise. I hope this version works better:

long main () {
    char output;
    unsigned char shift;
    long temp;
    
    if (i < 152) {
        shift = (~i & 1) * 7;
        temp = b[i >> 1] >> shift;
        i++;
        output = (char)(64 & temp);
        output += (char)((n >> (temp & 63)) & main());
        printf("%c", output);
    }

    return 63;
}

EDIT: I just got a chance to compile it and it does work.