I believe the second case is quite obvious too, with function inlining (assuming that GP post just forgot to define a and b as constants.)

In the second case the divide function isn't being exported from the compilation unit and the compiler can tell[1], so the compiler is free to do whatever it wants with the calling convention and in this case it will choose to inline. And once it's inlined finding the correct answer at compile time is still obvious.

[1] Normally you have to declare a function as 'static' to tell the compiler that the function isn't being exported form the compilation unit, since the compiler isn't supposed to be able to tell the difference between function declarations in the .c file itself and function declarations that were included from .h files. But in this case the function is just defined and never declared, so I presume that's the same as a static declaration.

As mpyne explains, the function still is externally visible.

However, the compiler is perfectly free to both compile it as an external function and inline it wherever it wants. Yes, setting breakpoints on such a function would be 'funny', but that's nothing of real concern to the compiler.

No, it's still an extern declaration. However the compiler is still allowed to "peek within" an extern function as long as it has the definition available.

You can see this by inspecting the disassembly yourself, you'll see that printf never actually calls divide, and yet the divide function is still defined within the executable output.

I think LeafStorm meant to put some constants in the divide call.

Yeah, I did. Sorry about that.