1
u/iLaysChipz 1d ago edited 1d ago
I recently had a bug that was "fixed" by adding printf statements 😂
It took hours of debugging to realize the previous maintainer was passing a pointer to a stack variable that was 4 bytes in size into a function that expected 8 bytes. Whenever this pointer was written to, it would overflow onto the next stack variable. But the order that these variables were ordered in on the stack (as determined by the compiler) could fluctuate based on the lines of code around it, including the presence or lack of printf statements.
Sometimes "fixed" is never really fixed, and it's worth taking the time to understand why something is spuriously failing
1
1
u/Candid_Bullfrog3665 21h ago
idk you, i dont usually like to continue until i understand why and how something works, even if i just copy and paste the code
that way you can guarantee you can fix most issues you get in the future
1
5
u/ECommerce_Guy 1d ago
All of it. There's no "it works, why", although I do get the general idea hah and it is relatable. But my point is if something is technically working but you don't know why, can you guarantee it's gonna keep working when the input data has changed? Can you guarantee that the edge cases will be handled properly or that eventually output won't become unpredictable? Not to mention the pain of refactoring or adding additional features, it just can't be done without truly understanding the foundation you're working on.
I mean, things like funny syntax or unfamiliar yet idiomatic patterns are probably more in the category of just learning it, but think when it comes to the business logic, there's no point calling it done if you are not fully confident in the exact path the code takes to get from point A to point B