this post was submitted on 10 Nov 2024
201 points (95.5% liked)

Programmer Humor

32706 readers
230 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
top 19 comments
sorted by: hot top controversial new old
[–] cmnybo@discuss.tchncs.de 41 points 1 month ago (3 children)

You don't get segmentation faults if you don't have an MMU. That can certainly make debugging more interesting when your firmware starts overwriting memory that it shouldn't until it finally crashes.

[–] TimeSquirrel@kbin.melroy.org 25 points 1 month ago (1 children)

Sometimes you'll notice the side effects, like if you have a small OLED or LCD screen and start getting garbage characters in your strings.

[–] qprimed@lemmy.ml 18 points 1 month ago

or, if you are really lucky, you can poke the right locations and release the magic blue smoke from the chips. super fun and all the cool kids are doing it.

[–] mkwt 12 points 1 month ago* (last edited 1 month ago)

Even if you do have an MMU, there's no guarantee that you'll get a segmentation fault from a memory bug. You can still just get the weird side effects, if you fail to access the incorrect memory.

Undefined behaviour means exactly that. You have no idea what you could get.

[–] litchralee@sh.itjust.works 11 points 1 month ago

I was once working on an embedded system which did not have segmented/paged memory and had to debug an issue where memory corruption preceded an uncommanded reboot. The root cause was a for-loop gone amok, intending to loop through a linked list for ever member of an array of somewhat-large structs. The terminating condition was faulty, so this loop would write a garbage byte or two, ever few hundred bytes in memory, right off the end of the 32 bit memory boundary, wrapping around to the start of memory.

But because the loop only overwrote a few bytes and then overflew large swaths of memory, the loop would continue passing through the entire address space over and over. But since the struct size wasn't power-of-two aligned, eventually the garbage bytes would write over the crucial reset vector, which would finally reboot the system and end the misery.

Because the system wouldn't be fatally wounded immediately, the memory corruption was observable on the system until it went down, limited only by the CPU's memory bandwidth. That made it truly bizarre to diagnose, as the corruption wasn't in any one feature and changed every time.

Fun times lol

[–] riodoro1 21 points 1 month ago (1 children)

I made a mistake in my code.

No, it must be the language thats unsafe!

[–] bleistift2@sopuli.xyz 11 points 1 month ago (1 children)

If you cut yourself with a knife, it might be your fault. And it might be that the knife is sharp on both sides and has no handle.

[–] riodoro1 7 points 1 month ago* (last edited 1 month ago) (2 children)

Posted on gigabytes of robust C/C++ codebase.

You cannot make a safe yet universal cutting tool. If it needs to cut, it can also cut the user. Its completely up to the user what he chooses to do with a knife and there have been many „accidents” with them. Yet we keep making and using simple knives in a form unchanged since before we could write.

[–] stetech 4 points 1 month ago* (last edited 1 month ago) (1 children)

You cannot make a safe yet universal cutting tool.

I’m neither language designer or crustacean advocate, but from what can be read, Rust seems to have managed just fine. The trick is probably to allow removing the cover of the sharp edge when needed (execute unsafe).

[–] lord_ryvan@ttrpg.network 2 points 3 weeks ago

Also, Rust allows "unsafe" code for when it's absolutely necessary; you DO need to add a line that basically says "I know compiler, don't stop me". To keep up the metaphor; Rust allows you to cut yourself with the knife, but ensures you're fully aware of what you're doing.

[–] HStone32 18 points 1 month ago

Memory safety is a skill, not a feature.

[–] davel@lemmy.ml 11 points 1 month ago (1 children)
$ echo 'main;' > main.c && gcc main.c 2>/dev/null && ./a.out
Segmentation fault (core dumped)
$ 
[–] TunaCowboy 9 points 1 month ago (1 children)

echo 'main;' | gcc -w -x c - && ./a.out

[–] perry@lemy.lol 4 points 1 month ago* (last edited 1 month ago) (1 children)
echo 'int main;' | gcc -w -x c - && ./a.out
[–] Tenkard@lemmy.ml 12 points 1 month ago
echo "Segmentation fault (core dumped)"
[–] logging_strict@lemmy.ml 10 points 1 month ago

Write a post that leads back to a tiresome obvious discussion about a particular coding language without mentioning that coding language

now rinse wash and repeat until our eyes have no blood left to bleed

[–] db2 1 points 1 month ago (1 children)

Support for the a.out format was deprecated in Linux kernel version 5.1, and support for the format was removed across the 5.18 and 5.19 kernel releases.

https://en.wikipedia.org/wiki/A.out

[–] mkwt 4 points 1 month ago

For "reasons" GCC outputs "a.out" as the default file name, even if the output format is actually, ELF, PE, or whatever.

Override this behaviour with the -o option.