Quirky/interesting programming problems

[dr froyd]

i don't know how many people program in here but....
i sometimes come across some interesting problems and i will keep posting them here

 

[dr froyd]

recent one (trying to refresh some C++ knowledge)

function overloading can create some very confusing scenarios. E.g. what will this program print:

#include <iostream>

void foo(unsigned int x){std::cout << 10 * x << "\n";}
void foo(int x){std::cout << 100 * x << "\n";}
void bar(int x){std::cout << 100 * x << "\n";}

int main(){
    unsigned int s = 1;
    foo(1);
    foo(-s);
    bar(-s);
    return 0;
}

answer:

Spoiler

100
4294967286
-100

- foo(1) will be 100 because the "1" literal is int (unsigned would need to be "1u")
- foo(-s) will compute unary minus on a (32-bit) unsigned int, which will wrap around using two's complement, and then call foo(unsigned int x).
- bar(-s) will also first calculate 4294967286 but then interpret the bytes as int which will lead back to -1, and then print -1 * 100

 

[Cognisant]

I wonder if this could be exploited for encryption somehow, make it mathematically unbreakable because the math doesn't work unless you run it on a machine that handles variables a particular way. Bad math on purpose.

Disclaimer this is waaaaay out of my wheelhouse.

 

[dr froyd]

it would actually be interesting to see if anyone got a different output from that program.. but i assume int / unsigned-int is 32 bits and use two's complement logic for everyone

btw i asked like 7 different LLMs what the output would be - all got it wrong

 

[birdsnestfern]

Not for a living. I was best friends with a programmer from Tennessee for a while, but prior to that, I took courses in Cobol programming 1 and 2 and System Design and a lot of programming math, but switched to accounting as it was more my thing. I found the hardest part was just working the bugs out of business objects and page parameters, some of that coding is three pages long for a tiny output. Then, I was asked to design a system program that helped a real navy submarine base order nuclear sub parts to upgrade the equipment using RFQ's (procurement). I turned mine in as my final exam and it got an A, nobody else could do it so the teacher called everyone over to his house, this was a two hour drive in the rain for a different final late at night, pfft. Students last minute complained they couldn't do it. It was basically a system that would re order parts, but you have to have a lot of imagination and knowledge to know what parts will need to be replaced on a submarine or on a base in general, omg, lol.

 

[dr froyd]

@birdsnestfern thats impressive. I have real respect for people who programmed stuff back in those days

 

[birdsnestfern]

Well, this was not too long ago, about 1999-2000. Anyway, C+ looks very complex, that was impressive that you can do that.

 

[dr froyd]

oh ok, i took it as you implemented that stuff in Cobol.. which would be unusual in 1999 Lol. But maybe it was indeed Cobol, i know some finance institutions still run it as legacy code

C++ sucks btw, but it's useful

 

[dr froyd]

observation on programming with LLMs

one of the ostensible benefits of LLM is that you can jump into languages/libraries quickly without knowing them too well.

but there's a severe downside to that, which only becomes apparent when you need assistance the most.

once the LLM doesn't get things quite right, and you don't know exactly how to make it right, you're off to a wild goose chase where questions result in more questions, errors create more errors, you diverge from what you want to achieve, and code gets messier in a self-reinforcing fashion.

and what's worse, the rate at which the LLM "doesn't get things quite right" increases rapidly as the size and complexity of the program grows.

conclusion: read the fucking manual and don't rely on LLMs