Can I include compiler bugs? I've had to deal with a slew of those over the years.
If we put those aside, then the simplest example is probably when someone else's code crashes due to your input (though the bug may be theirs), and you don't have their source code. I've spent a great deal of quality time tracking down bugs in vendor libraries for which I had no source, and then working around them.
There are a ton of other possibilities, though. For instance, ordering issues related to thread-safety, out-of-order execution, and synchronization points/barriers.
Or, hell, just being able to read a failure quickly, whether or not you have debug symbols handy. Contrived example:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000100000f25 in main ()
(gdb) disassemble
Dump of assembler code for function main:
...
0x0000000100000f25 <main+21>: movb $0xff,(%rax)
...
End of assembler dump.
(gdb) info reg rax
rax 0x0 0
I think this is a valid example of reasons where it would be helpful to know assembly as a C programmer, but not justification for the claim that writing C without knowing assembly is writing code you can't debug.
Even if you are having problems interfacing with a third party library, most of this stuff is pretty Googleable.
I think a good summary of my opinion would be that if you're going to primarily write C professionally throughout your career, it's best to understand fundamentals of assembly, but doing projects here and there? I don't think it's worth the time; you just won't use it that much.
Comments
Can I include compiler bugs? I've had to deal with a slew of those over the years.
If we put those aside, then the simplest example is probably when someone else's code crashes due to your input (though the bug may be theirs), and you don't have their source code. I've spent a great deal of quality time tracking down bugs in vendor libraries for which I had no source, and then working around them.
There are a ton of other possibilities, though. For instance, ordering issues related to thread-safety, out-of-order execution, and synchronization points/barriers.
Or, hell, just being able to read a failure quickly, whether or not you have debug symbols handy. Contrived example:
I think this is a valid example of reasons where it would be helpful to know assembly as a C programmer, but not justification for the claim that writing C without knowing assembly is writing code you can't debug.
Even if you are having problems interfacing with a third party library, most of this stuff is pretty Googleable.
I think a good summary of my opinion would be that if you're going to primarily write C professionally throughout your career, it's best to understand fundamentals of assembly, but doing projects here and there? I don't think it's worth the time; you just won't use it that much.
C isn't the kind of thing you dabble in.