4 ms·

I agree with the wrong title for that article, But, why do you think that understanding C by learning assembly is a terribly wrong-headed idea? Some professor

by vmarsy 11y ago

I agree with the wrong title for that article, But, why do you think that understanding C by learning assembly is a terribly wrong-headed idea? Some professors tend to disagree and prefer a bottom up approach of learning. The main advantage is : you get rid of the "magic" of computing. http://www.ncsu.edu/wcae/WCAE2/patt.pdf http://www.ncsu.edu/wcae/WCAE2/patt.pdf https://www.youtube.com/watch?v=J926i6MwRpo https://www.youtube.com/watch?v=J926i6MwRpo

ejcx 11y ago
I definitely agree with this. I had "learned C" but not really (programmed small things in it). Then about a year later I ended up taking a course that involved a lot of reverse engineering and analysis of ELFs. Later on I went back to C since I knew I had never really done a lot with it and everything was a breeze. I understood what was going on, loved it, and on top of that was able to easily knock out loads of exploitation stack-smashing puzzles I found on the internet. I already knew how to program pretty well but didn't really know system programming and C. I can imagine the value of, instead of writing hello world, learning assembly first and writing programs that end with some exit status instead. It would probably be way more boring, but way more informative in the long run.
0x09 11y ago
The thing is, C does contain quite a bit of "magic" built into the transformations a compiler is allowed to do to your constructs. A mental model of C built on the mapping to assembly is appealing, but leads to false intuition when reasoning about the language's rules, which occasionally has disastrous effects. Just as an anecdote, I have seen a surprising number of C programmers assume that the language's type aliasing rules are related to or somehow governed by pointer alignment, when these are entirely separate. The former exists to facilitate analysis and optimization at the compiler level -- there is no "ground" reason. It's important not to get trapped in the portable assembler mindset and lose sight of an entire level of transformations that might not have an intuitive relationship with hardware.
kazinator 11y ago
Probably, the most succinct way to articulate this is that: a given piece of C can be translated in countless ways into just one assembly language, and not all those ways may behave the same as each other or as what someone expects. Then, it can also be translated into other assembly languages, including an unlimited supply of imaginary ones. None of the translations define the behavior.

by vmarsy 11y ago

ejcx 11y ago

I definitely agree with this. I had "learned C" but not really (programmed small things in it). Then about a year later I ended up taking a course that involved a lot of reverse engineering and analysis of ELFs. Later on I went back to C since I knew I had never really done a lot with it and everything was a breeze. I understood what was going on, loved it, and on top of that was able to easily knock out loads of exploitation stack-smashing puzzles I found on the internet. I already knew how to program pretty well but didn't really know system programming and C. I can imagine the value of, instead of writing hello world, learning assembly first and writing programs that end with some exit status instead. It would probably be way more boring, but way more informative in the long run.

0x09 11y ago

The thing is, C does contain quite a bit of "magic" built into the transformations a compiler is allowed to do to your constructs. A mental model of C built on the mapping to assembly is appealing, but leads to false intuition when reasoning about the language's rules, which occasionally has disastrous effects. Just as an anecdote, I have seen a surprising number of C programmers assume that the language's type aliasing rules are related to or somehow governed by pointer alignment, when these are entirely separate. The former exists to facilitate analysis and optimization at the compiler level -- there is no "ground" reason. It's important not to get trapped in the portable assembler mindset and lose sight of an entire level of transformations that might not have an intuitive relationship with hardware.

kazinator 11y ago

Probably, the most succinct way to articulate this is that: a given piece of C can be translated in countless ways into just one assembly language, and not all those ways may behave the same as each other or as what someone expects. Then, it can also be translated into other assembly languages, including an unlimited supply of imaginary ones. None of the translations define the behavior.