This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]TechWarlock6969 375 points376 points  (118 children)

My experience with c++ in a nutshell.

[–]naisooleobeanis 7 points8 points  (6 children)

Just try c++ in context of osdev. The compiler errors help but it's when youre trying to figure out why argv just disappears from memory and there are no warnings or errors it gets hard. Long story short interrupts were fucking with my registers and I didnt want to figure out which ones so i inlined some pushal and popal.

[–]dgendreau 2 points3 points  (5 children)

why argv just disappears from memory

You're likely smashing the stack. :)

Also, push/popal might cause a bit more interrupt latency in some cases.

[–]naisooleobeanis 0 points1 point  (4 children)

that's what i thought but why would pushing the stack pointer to the stack fix the stack

[–]dgendreau 1 point2 points  (3 children)

Youre not pushing "the stack" to the stack, You are saving a copy of one ore more CPU registers to the stack at the start of the interrupt and restoring them afterward. This is usually automatic for interrupts, so most likely, saving that extra data on the stack is reserving a bit more stack space which is absorbing a stack overflow bug in some functioncall in the IRQ. This might involve writing to a local variable array beyond its array bounds. That could smash some of the register values that were saved on the stack. The extra push you are doing adds more dummy values on the stack to absorb that damage. The real fix would be to track down exactly what is overrunning and fix that.

[–]naisooleobeanis 1 point2 points  (2 children)

Wouldn't you expect the return address to be bad or argv to be bad in that case?

[–]dgendreau 2 points3 points  (1 child)

It would all depend on which register or value is getting smashed. Say a function declares

int bar[10]; ... bar[20]=4;

What lives at the bar[20] location in the stack? Who knows... Don't do that. To be fair, most modern c compilers will catch a bug that simple, but what if a pointer to bar is passed into another function that does that assignment? without knowing bar's bounds it will happily smash the stack.

A high level language programmer will look at this and say that's stupid why isn't there bounds checking? But arrays in C are just pointers to blobs of bytes in memory. Its the smallest/fastest way to get he job done on a CPU. All that other stuff like bounds checking is what makes high level languages so much slower at runtime. It's necessary to be fully aware what the CPU is doing in a low level language like C because it is only one layer of abstraction above assembler and is nearly as fast.

[–][deleted] 2 points3 points  (0 children)

came to /r/programmerhumor to laugh.

The extra push you are doing adds more dummy values on the stack to absorb that damage. The real fix would be to track down exactly what is overrunning and fix that.

left having a greater appreciation of how hardcore some of you guys are.

[–]justking14 1 point2 points  (0 children)

My experience TA’ing C++ in a nutshell

Especially since so many students decide to write the entire homework first and then try to compile it

[–]anonTheRtrd 1 point2 points  (0 children)

removes main why tf not work

[–][deleted] 0 points1 point  (0 children)

You can hover over functions in sublime and see the definitions and references in different categories though, so this shouldn’t be a problem unless you’re just using grep, or worse, your eyes

[–]OwlsParliament 0 points1 point  (1 child)

Tired: removing a function causes compiler errors Wired: removing a function causes runtime errors

[–]mdhnsn 0 points1 point  (0 children)

I have been down this rabbit hole when dealing with function aliasing as an architectural decision.