question on embedded-resources/interview/bad.c

[chintan09]

could you add context around bad c code analysis. it is not very clear just reading bad.c file.

[phillipjohnston]

I will do a more formal write-up of it, but I am leaving for a road trip tomorrow so it will be on my return :). Here are some quick notes for you: I like this question because you can make it as simple or complex as the situation/candidate allow. This question provides a platform for discussing: Function entry/exit implementations at a deeper level How does the stack work What is the impact of undefined code? How do optimizations affect the code? I start the interview by writing those functions on a white board and then asking the candidate "What does this program output when run?" Based on the response I investigate in the directions above and dig as deep as I can until the candidate hits their knowledge limit: Can't figure out what the program outputs? I start asking how local variables in functions are stored (on the stack) and how the compiler actually handles the stack when entering and leaving functions. If they have enough low level knowledge, you can lead them through the rest of the problem (hopefully) If they can figure out what is output, I ask them to explain themselves and start digging deeper based on what they are saying to me. I try to stick to the areas highlighted above. The expected output WITH NO OPTIMIZATIONS ON is that first you see 5, then you see 6 printed. The uninitialized variable "a" in bar grabs the value of the memory, which just so happens to be initialized ot "5" from the previous function. This behavior is not guaranteed, because it is undefined - implementations can vary, though most follow this pattern. I might ask what would cause the output to vary? If the stack is handled differently, this can change. If there are other initializations or function calls in between, this behavior can vary - you're just getting junk data If you turn on optimizations, all bets are off. You can have unused variables discarded, so foo() isn't even doing anything. And perhaps that function gets stripped out completely. Your stack variables could be placed into registers, and you have no guarantee that you'll pick up the last functions initialized value for that memory - a little interrupt could mess everything up. I also might ask "why does this even work?" and start discussing: undefined behavior the benefits of undefined behavior to compiler implementers the dangers to developers the problems with relying on undefined behavior for your program to function correctly Hope this helps! Cheers, Phillip

…

On 10May2017, at 08:01, Chintan Parikh ***@***.***> wrote: could you add context around bad c code analysis. it is not very clear just reading bad.c file. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABoUB_6dQQ95_lk4FDcZmd1CUKlQWOJRks5r4dFCgaJpZM4NWy6s>.

[chintan09]

Thanks for the detailed write up, interesting question.