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

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.

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.

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.

"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 :)"

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)

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.

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.

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.

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!

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.

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

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?

FWIW: These are the compiler flags I typically use:

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

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

...and reading code.

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?

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.

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?

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);).

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/

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."

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

-1, Learn don't guess.

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

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.