this post was submitted on 14 Sep 2025
836 points (98.8% liked)

Programmer Humor

26332 readers
2313 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 2 years ago
MODERATORS
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev
836
RTFM (eviltoast.org)
submitted 22 hours ago by orhtej2@eviltoast.org to c/programmer_humor@programming.dev
53 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] Jankatarch@lemmy.world 20 points 19 hours ago* (last edited 19 hours ago) (3 children)

It doesn't work the first time but you copy paste from the docs example instead of typing the example and it works now

[–] ChogChog@lemmy.world 6 points 15 hours ago

Ohhh, so that’s why it’s called Docker!

As in “It works on my system” so they just copied and pasted the commands for you.

[–] Probius@sopuli.xyz 14 points 19 hours ago (3 children)

I've had times where I was going through my code and the docs code step by step to see where they logically differed and found that I was doing all the same things, but my code didn't work and copy-pasting their code did. Make it make sense!

[–] aaaa@piefed.world 15 points 17 hours ago

Let me count the ways it has been for me... Capitalization, using -, not using -, wrong quotes, mismatched quotes, no quotes, reading the command the same wrong way about five times and typing it that way. Well this could take forever to list them all.

I just copy paste first now. That way I learn none of the commands or syntax at all

[–] raspberriesareyummy@lemmy.world 5 points 18 hours ago (1 children)

Been there, found undefined behavior where there should not be any. Imagine a function that takes a bool param with the following code, but neither branch gets executed:

if (b)
   doStuffForTrue();
if (!b)
   doStuffForFalse();

In a function that is passed an uninitialized bool parameter, in gcc compiler, both branches can get executed even when b is const. Reason: uninitialized bool in gcc can have values of a random integer, and while if(b) {} else ({} is guaranteed to execute only one branch, bool evaluations of a bool value take a "shortcut" that only has defined behavior with an initialized bool.

Same code with an uninitialized integer works as expected, btw.

[–] zerofk@lemmy.zip 2 points 10 hours ago (1 children)

Don’t blame this on gcc or the library/function author - it is 100% user (i.e. programmer) error. Uninitialised memory of any type is undefined behaviour in the C and C++ abstract machine. That means optimising compilers can assume it does not exist.

For example, the compiler could see that your ‘b’ is never initialised. Therefore, using it would be undefined behaviour. So, the optimiser can assume it is never used, and it is as if that code simply does not exist: the behaviour you saw.

I’m not saying that is what happened, nor that it will always happen, but it is a possibility.

[–] raspberriesareyummy@lemmy.world 1 points 7 hours ago* (last edited 7 hours ago)

Don’t blame this on gcc or the library/function author - it is 100% user (i.e. programmer) error. Uninitialised memory of any type is undefined behaviour in the C and C++ abstract machine. That means optimising compilers can assume it does not exist.

I absolutely do blame this on the C++ standard being not specific enough, specifically for the way in how I learned about this: When writing a trivial function, you would never expect that - for a bool parameter - an "if (b)" branch can be executed as well as an "if (!b)" branch.

So basically, this mechanic sabotages input data validation in functions that test whether plausible parameters were provided. The problem is that a function you write that is bug-free and "perfect code" - despite input data validation - can exhibit undefined behavior due to an uninitialized bool type parameter. Something that can not happen with other uninitialized trivial (numeric) data types (int, float). Simply due to the way boolean checks are translated to x86 assembly:

Here's an example: https://godbolt.org/z/T3f9csohd

Note the assembly lines 176-182: The only difference for the "if (!b)" check is that the lowest bit of the boolean is flipped with an xor - which assumes about the implementation that a boolean can never hold values other than 0 or 1. Which I - as a naive user - also assumed until this happened. Correction: I assumed that negating a bool would result in the inverse boolean value.

So the problem boils down to: The value range of any given (built-in) numerical data type fully encloses the value range that an uninitialized variable of that type can have. This is not necessarily true for boolean: In g++, the value range is [0;1] and the range of an uninitialized bool is [0;255].

Accordingly, I would expect the C++ standard to fix this by stating that an uninitialized bool must have a value for which only one of two conditions evluates to true: b or !b, but not both.

[–] RampantParanoia2365@lemmy.world 4 points 18 hours ago

I find myself saying this about 35 times a day, at nearly every turn, with about everything I interact with.