3 ms·
C conceptually is the nearest layer to the hardware that you'll get outside assembler. What that means is that most C operations can be easily translated into t
by sys_64738 8y ago
C conceptually is the nearest layer to the hardware that you'll get outside assembler. What that means is that most C operations can be easily translated into the machine code equivalents and that makes debugging of compiled code so much easier. A disassembly of many binaries will reveal their C roots by function calls being equivalent to jump statements, as an example. If you have the C source then you can usually figure out what's going on.
That simplicity and the smallness of the C language makes it truer to the hardware underneath and as you don't need to descend through layers of frameworks, like a high level language such as python, to understand what the heck is going on.
- geofft 8y ago> What that means is that most C operations can be easily translated into the machine code equivalents and that makes debugging of compiled code so much easier. A disassembly of many binaries will reveal their C roots by function calls being equivalent to jump statements, as an example. If you have the C source then you can usually figure out what's going on. This is very much not true in my experience. Optimization (even just -O1, which is required to make C be more worth writing than Python for large-scale apps) will do things like reorder statements, inline functions, elide local variables, set up tail calls, etc. It is a specific skill requiring experience to be able to understand what's happening when stepping through a C function in a debugger, even with source at hand and debugging information included. If you haven't been frustrated at "Value has been optimized out" or breakpoints being mystically skipped, you haven't done enough debugging work to really acquire this skill, and saying that C maps to the machine is just theory. There is value in a highly unoptimized language toolchain for debugging, sure. But honestly CPython is closer to that than any production C binary you're likely to see.
- jimmaswell 8y agoWhy would you turn on optimization while debugging?
- tomjakubowski 8y agoSometimes the bugs don't happen when optimizations are off. (-:
- jolmg 8y agoThat'd be a compiler bug, then. I don't think those would be common. EDIT: I suppose the other possibility is that the program is doing some weird things, like reading its own machine code from memory.
- lmkg 8y agoOr undefined behavior in the program, which happens to manifest differently under different compile options.
- geofft 8y agoNeither of the above are required: your code might be racing with some other API. If your code finishes fast enough, the other code isn't ready for you. With optimizations off, you consistently lose the race and the bug doesn't show up.
- monocasa 8y agoOnce you get used to it, it's not terrible. I don't debug on anything other than release builds (but with symbols) so that I know that I'm debugging the actual issues.
- geofft 8y agoBecause you're debugging a failure in production code. Extraordinarily common.
- pjmlp 8y agoBecause with them turned off, the executable might not fit on the target platform, for example. Quite common on games targeting consoles.
- sys_64738 8y ago
- pjmlp 8y agoYou can get that as well with NEWP, PL/I, Extended Pascal, BLISS, Modula-2 and tons of other system languages.
- sys_64738 8y agoMaybe but there's a reason C emerged as the winner because none of those systems really has an established reference model to look at. C has several - e.g. UNIX being written in C.
- pjmlp 8y agoUNIX being available for free with source code is what helped C gain adoption. The nomimal fee universities had to pay AT&T was meaningless compared to what something like VMS or OS/360 would cost them.