Where to begin when learning C? Start by making lots of errors

http://morganwilde.svbtle.com/where-to-begin

by morganwilde • 13 years ago

68 89 13 years ago

morganwilde.svbtle.com

morganwilde9• 13 years ago

By the way, I would love any feedback on this approach and where I should take this further.

e12e4• 13 years ago

I'm surprised no-one's mentioned it yet, but this approach should go well with Zed Shaw's Learn C the Hard Way:

  http://c.learncodethehardway.org/book/

e12e4• 13 years ago

As for going further staying with the bare-bones approach, I suppose you'd have to start looking at assembly output and how that fits with what the c-code does. I don't know anything about OSX x86_64 calling conventions etc -- but at least under Linux (and afaik windows) 64bits is a lot more friendly and fun than the mess that was 32bit (and 16bit) x86.

There are a couple of great (free) resources on 32bit x86 assembly I'm aware of:

http://www.drpaulcarter.com/pcasm/ http://www.plantation-productions.com/Webster/HighLevelAsm/i...

There's apparently some plans on upgrading HLA to x86_64 -- I don't know of any good tutorials or guides on working on 64bit assembly specifically I'm afraid.

Just adding "-S" and looking at the source can be helpful of course, although I much prefer nasm/intel syntax, for clang/gcc that should require:

   clang -S -mllvm --x86-asm-syntax=intel main.c
   gcc -S -masm=intel main.c

Note that gas syntax is the "default" in the gnu-world, so it might be easier to just go with that if you're just starting out.

It looks like clang might be generating less "noise" for tiny trivial programs, here's a side by-side-diff (in intel syntax) of int main{} vs int main { return 0;} (slightly reformatted):

    diff --side-by-side main.s main.no-ret 
      .file   "main.c"                          .file   "main.c"
      .text                                     .text
      .globl  main                              .globl  main
      .align  16, 0x90                          .align  16, 0x90
      .type   main,@function                    .type   main,@function
    main:                       # @main       main:          # @main
      .cfi_startproc                            .cfi_startproc
    # BB#0:                     # %entry      # BB#0:        # %entry
      mov     EAX, 0                             mov     EAX, 0
      mov     DWORD PTR [RSP - 4], 0         <
      ret                                        ret
    .Ltmp0:                                   .Ltmp0:
      .size   main, .Ltmp0-main                 .size   main, .Ltmp0-main
      .cfi_endproc                              .cfi_endproc

      .section ".note.GNU-stack","",@progbits   .section ".note.GNU-stack","",@progbits

It can be fun to do this with stuff like hello world (and contrast puts("Hello, world!"); with printf("Hello world!\n);).

morganwilde9• 13 years ago

e12e, this is something I didn't think about, but fits perfectly into me theme of "zooming out". Thanks!

pjmlp7• 13 years ago

Intel x86 assemblers family are so much nice that whatever any UNIX system has.

jdeisenberg• 13 years ago

The error message says: Undefined symbols for architecture x86_64: "_main" (etc.) If someone truly knows nothing about C, how does that person go from that error message to "In the case for C, the entry point is defined by the “main()” function." I'm not clear on where the beginner is going to go to "dig deeper and understand what it is that it’s trying to say."

pjmlp7• 13 years ago

By making sure to enable all warnings, enable warnings as errors and use a compiler that integrates static analysis like clang.

morganwilde9• 13 years ago

I am using the default `cc` compiler on Mac OS X for this without any flags, are you saying I should something non-stock in this case?

enqk2• 13 years ago

Try passing at least the -Wall and -Wextra flags.

For learning, you could also add -ansi, as it will make your compiler be stricter about standards.

pjmlp7• 13 years ago

The Mac OS X C compiler is clang, no need to install anything extra.

C is insecure by design and IT is still paying for its widespread, when used by developers that don't use the best practices for secure C coding.

So when learning how to use it, the best way is to learn those best practices from day one.

enqk2• 13 years ago

It's essential to follow pjmlp's advice, since C does otherwise not give a lot of feedback about one's mistakes: learning from one's mistakes might take a long time since a quite broken program (think overwriting past memory strictly allocated for one entity) might still lead to a working program.

Use your compiler, use it well with all its warnings. Run your programs under valgrind or some such.

Keyframe• 13 years ago

or with GCC: gcc -ansi -pedantic -Wall -Werror or exchange -ansi with -std=c99 later on when you grasp the core of c89.

lvillani• 13 years ago

FWIW: These are the compiler flags I typically use:

    -std=c99 -Wall -Wextra -Werror -pedantic-errors

rdc12• 13 years ago

One I have been meaning to try with Clang is, -fcatch-undefined-behaviour

kabdib2• 13 years ago

I learned C by reading K and R and doing the book's exercises . . . on paper. At the time I didn't have access to a C compiler, so I wrote them all out in a notebook. A month later I got a job at a shop that was running Unix, and got the chance to type my programs in and try them.

I had a lot of things wrong. It took me a while to understand the difference between control-D and EOF, for instance (how embarrassing). But the 30 days I spent without a compiler made me think about program behavior.

I'm not saying this is a great way to learn a language, but it can be done.

I keep hearing people complain about K and R being "a terrible book." For me it was perfect: pragmatic, succinct, with great examples and good exercises.

morganwilde9• 13 years ago

I guess this is sort of I'm thinking about this, that is forcing people first to think how something should work, rather then just duplicating some code and seeing that it works. Thanks for sharing!

jaxytee• 13 years ago

I find the visceral act of manually writing code to be an extremely effective tool when learning programming language syntax. I find it similar to the "Write these words 10 times" technique used when teaching grade school kids how to spell and read.

gits1225• 13 years ago

"Programming is learned by writing programs"

- Brain Kernighan

And that is what anyone who goes through K&R will do: Reading and writing lots of real programs. A simple program is worth a thousand words!

Which unfortunately the majority of technical books just can't get right. Explain the concepts in 5 full dull pages, and then at the end "Hey, checkout this little snippet of code, which by the way does nothing really interesting, but is here to illustrate what the author was talking about :)"

clarry• 13 years ago

I'd like to add some emphasis on reading. For a beginner, writing is obviously very very important as the way to get to the point where he can just sit down and solve a given task.

But reading lots and lots of code (from many different sources) will help him pick up idioms and find common & good solutions to specific problems. Even for a smart person, I think it'll take a lot of time and effort to arrive to the cleanest way of doing things.

Of course there's a risk of picking up bad habits, but if you read lots of code, you should eventually develop a feel for what's clean and readable and easy to understand, and what's messy and wrong. This sadly doesn't help with issues like undefined behavior, but you don't learn these just by writing either. For that you need to look into the spec or some other text that'll cover these.

EDIT: I like to think that I'm a fairly good C programmer (having coded nearly all my life, with C mostly), but I still peek into others code all the time to find out how they've solved some things I'm about to do.

DanWaterworth• 13 years ago

A simple program is worth a thousand words!

Whereas, the less said about complicated code, the better.

wglb2• 13 years ago

And that may give you a leg up on the rest of us. Not enough thinking of this sort gets done.

In fact, this is how one of the great teachers of CS, Dijkstra, taught computer science.

I have been known to complain about the second edition--the first is the one that I go back to. But it is an absolutely fundamental book for understanding the practicality of programming. I agree with your assessment.

pjc50• 13 years ago

People don't like K&R? I can understand it not being suitable for children and the very beginner, but it's one of a very few programming books that is useful, succinct, pragmatic, doesn't get bogged down in APIs, and is written clearly.

(The companion book "Programming in the UNIX environment" is the get-you-started guide from the very beginning, although it assumes 1970s terminal defaults)

ExpiredLink2• 13 years ago

K&R is the best second C programming book.

josephlord2• 13 years ago

It's great but it gives you enough knowledge to be dangerous without sufficient warnings of the dangers or about modern best practice.

As part of broader reading it is deservedly a classic. Alone pretty terrifying.

csmuk• 13 years ago

That's great. I learned C by telling people I had C experience then when I got a job offer I was forced to learn it pretty quickly over a weekend powered by coffee and yorkie bars and a pirate copy of Microsoft C. I had plenty of experience with assembly at the time.

fortunately I wandered into a company that had even less of a clue than me. It's nice to be an expert on day one with only two days' of expertise :)

I learned a hell of a lot in a year. Great year.

tptacek• 13 years ago

This situation is why there is "hello world"; that program seems trivial but actually has important implications; for instance, that your environment works, that you know how to feed programs to the compiler, that you can actually run the output.

I never took "hello world" seriously until I started doing embedded systems work; it's now an extraordinarily important tool for me (I work an anomalously weird number of different environments).

mrmekon• 13 years ago

I once had a particularly slow week at work, and decided to write an article about how "Hello World" works in C. How it really works -- including compiling, linking, system calls, operating system involvement, hardware I/O, communication between ICs, etc. The path from the block of text to photons emitting from the screen, with fairly detailed explanations at every level.

I ended up with a 50 page LaTeX document that barely even scratched the surface, and then work picked up and I never finished it. A "full" explanation would probably be a 600+ page book.

I still think it would be a neat resource to have. We kind of take for granted that the simple "Hello World" is built on 60 years of research, and is anything but simple.

morganwilde9• 13 years ago

WOW, you should post that LaTeX document regardless of it being unfinished! Just the fact that you spent so much effort, requires some sort of release :)

wglb2• 13 years ago

I have often had the same idea, but more towards the goal of the intended audience being non-programmers.

But if you do finish this, I certainly would be interested in reading it.

purringmeow• 13 years ago

Can you please post it somewhere? I am really curious!

Aeolus98• 13 years ago

I second the motion to post the unfinished guide! Perhaps on Github where some other HN guys can make it complete for you.

Regardless, I think it's a great idea, and would really give insight as to why things work the way they do, instead of us just seeing Hello World!

jaredandrews• 13 years ago

This is the sort of thing I was looking for when I started wanting to understand the 'big picture' of computer programming. Would be great if you posted it!

oftenwrong• 13 years ago

I have been looking for a guide like that. I would also appreciate a release of the unfinished version.

joshavant• 13 years ago

This sounds like an outstanding Kickstarter project.

eliben• 13 years ago

My (admittedly, considerably more humble) attempt is http://eli.thegreenplace.net/2012/08/13/how-statically-linke...

It takes on an even simpler program, namely:

  int main() {
      return 42;
  }

But digs in the C runtime, Linux kernel and touches on compilers, linkers and loaders.

Hope it's helpful

chimeracoder• 13 years ago

How it really works -- including compiling, linking, system calls, operating system involvement, hardware I/O, communication between ICs, etc. The path from the block of text to photons emitting from the screen, with fairly detailed explanations at every level.

That reminds me of JBQ's blog post from shortly after Dennis Ritchie's death: https://plus.google.com/112218872649456413744/posts/dfydM2Cn...

I would love to see that document if you still have it.

rhgraysonii• 13 years ago

Please, please post this. Or if not would you be willing to share it privately? This is the sort of reading that really gets my rocks off. My email is in my profile if you're interested at all. I really would love to see this.

bitwize• 13 years ago

Agreed. "Hello world" is how you test that you are able to create a particular software artifact at the most basic level. My first kernel device driver was a NetBSD one called /dev/hello; it simply spit out "HELLO WORLD " over and over, for as long as you cared to read it. But it showed me how drivers do I/O and that I could write one and link it in.

neckbeard• 13 years ago

Another important outcome of a successful "hello, world!" is that you find some kind of MVP - Minimal Viable Printf.

Just because it is C doesn't mean you've got a sane libc. Let alone the luxury of a debugger. Just seeing that simple string on the screen/logfile can be a blessed relief.

mbq4• 13 years ago

Actually the message quoted complains about the lack of _main not main, so the rest of this post is a huge overinterpretation. _main is IMO some windoizm connected to the use of WinMain for GUI apps.

morganwilde9• 13 years ago

Are you trying to dispute the fact that `main()` is THE entry point for any C program? I'd be interested in hearing a more comprehensive explanation.

mbq4• 13 years ago

To some extent, _start is (https://blogs.oracle.com/ksplice/entry/hello_from_a_libc_fre...), so you can make a working program that has no main(). And in general entry points are a quirky land heavily dependent on OS and compilation stack.

deletes• 13 years ago

-1, Learn don't guess.

http://stackoverflow.com/questions/2627511/why-do-c-compiler...

mbq4• 13 years ago

Yeah, got me making the same error as I was complaining about. Thanks for the link though.

lhgaghl• 13 years ago

This is stupid. You should learn C properly (know how to avoid undefined behavior) or not at all. Exception if you're doing something that can tolerate remote code execution.

b0rsuk• 13 years ago

Install Valgrind. It makes error messages a lot less cryptic (my #1 problem with C... not that's it's limited to C). If you don't get proper feedback, it's not learning, just banging your head against the wall.

ufo• 13 years ago

In a similar vain, learn how to use a debugger, such as GDB or DDD. Even the bare minimum (getting a stack trace from a crashing/segfaulting program) is incredibly helpful.

adregan• 13 years ago

I've had a heck of a time getting Valgrind working on a mac (especially since Mavericks), hardly finding any resources about it. Is there an alternative, or do you have any advice on getting it to work?

mtdewcmu6• 13 years ago

XCode comes with profiling tools. It's not easy to stray outside of Apple's own development tools.

laveur• 13 years ago

This all of this!

yetanotherphd• 13 years ago

I think I have some ingrained fear of making errors, from the days where a simple error might cause your program to chew through your whole hard drive. Actually I don't know if that was ever the case, but that's how I felt.

Anyway, the hardest step for me in learning a language is when I take some running code and make one change to see what happens. Once I get in the swing of it, it gets much easier, but that first step is still hard to do.

passfree• 13 years ago

You should learn go instead of C.

morganwilde9• 13 years ago

A valid point longterm, but for different reasons that I have for discussing C.

foster1890• 13 years ago

Where to begin when learning C? Start at http://c.learncodethehardway.org/. It's going to be tough to top Zed Shaw's approach. The best way to learn code is by writing code.

jeffdavis• 13 years ago

...and reading code.

NAFV_P2• 13 years ago

Zed hasn't finished it yet. I'm dying to see this virtual machine of his.

vparikh• 13 years ago

In order to for people to really understand C and be proficient in it very clearly, I always recommend that they learn the basics of programming (memory, basic types, looping structures and array manipulation) in a simple assembly language such as 6502. This helps immensely with understanding pointers and deciphering the many cryptic C compiler messages.

mtdewcmu6• 13 years ago

A minor point, but important to understand: the error came from the linker, not the compiler. It compiled just fine.

joshguthrie• 13 years ago

Regarding that: >an empty file is not a valid C program, and the compiler will not hesitate to tell that to you with a big, fat error message.

Didn't someone win a IOCCC some years ago by providing an empty file that got compiled successfully?

mtdewcmu6• 13 years ago

Well, compiling an empty file is a piece of cake. An empty file is valid C, just not a complete program.

eonil• 13 years ago

I thinks this is a good approach. Checking most of possible exceptional cases while following regular learning course.

Errors = safety nets are usually the main reason to make stiff learning curve. This would be a great help for them.

idoescompooters• 13 years ago

Currently, I'm learning Python and have been learning it for over a year now. I've been thinking about moving to C as my next language. Is this a good idea? I'm eventually going to want to learn C++, but I'm not going to learn Java until I have to. Also, what are some really good C learning resources? I know there's K&R and learncthehardway.org

agumonkey• 13 years ago

As other people said earlier, reading existing code is great, when you have good sources. I'm an almost noob in C, and currently reading Ian Piumarta sources[1], I find they're superb in presentation and design.

http://piumarta.com/software/

[1] mostly for maru, his lisp system, but even tty2html (ascii control -> html) is very clean and elegant.

Where to begin when learning C? Start by making lots of errors

Related Stories