Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

He stated that 'you can get by', not that 'you can get by fine'.

Writing C without knowing basic assembly is writing code you can't debug. I'd say that's clearly not acceptable.



What's an example of a bug in C that cannot be diagnosed without knowledge of assembly?


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.


C isn't the kind of thing you dabble in.


Anything have to do with binary formats and I/O would qualify.

Let's say for example you're trying to load a binary file and the header format is like this:

16 bit magic number, 8 bit file size, 3 bit version, 5 bit header size

Now, are you confident enough in how structs are laid out in memory that you could use a bitfield to read these values in? Are you sure it would work on 32 bit, 64 bit, big and little endian machines? What is all that packed structure nonsense in GCC?

That's something that C abstracts away from you and can lead to errors.


I once worked with a png decoder which crashes with some input format. Later on found out it is an alignment issue, which requires some basic knowledge about Computer architecture and assembly of course.


A bug in C caused an alignment issue? That's pretty surprising to me. That should be abstracted from the programmer. If it was written in assembly, it makes sense, though.


> A bug in C caused an alignment issue? That's pretty surprising to me. That should be abstracted from the programmer. If it was written in assembly, it makes sense, though.

Memory alignment in C is most definitely not abstracted from the programmer. The compiler does add some padding to fit alignments but they can either work for you or against you. 98% of the time it works the way you want it but when it goes wrong, it's going to be a hard problem to debug. So it's absolutely critical for a C programmer to know a thing or two about alignment, especially the cases where the compiler attempts to fix it for you.

Examples of alignments that can have a performance effect or in some scenarios (multithreading, kernel programming) may affect the correctness of the program: 4 bytes (word size), 8 bytes (64b pointer size), 16 bytes (SSE/NEON SIMD register size), 32 bytes (ARM cache line size, AVX SIMD register), 128 bytes (ARM and x86 cache line size), 4k (ARM and x86 page size). Add relevant figures for any other target archs you're dealing with.

When doing GPU work (using glMapBufferRange or something), there are other alignments to care about and they may be GPU-specific. Aligning everything to 2^N can never hurt.


Not that hard. Apply improper member alignment via aligned/packed attributes, or hit a compiler bug, or just do something funny, and then execute code that requires specific alignment, like, say, an SSE code path in a PNG decoder that expects natural alignment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: