71–80 of 90 posts
By the way, I would love any feedback on this approach and where I should take this further.
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.
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 di…
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.
Earlier quoted context omitted.
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…
I have been looking for a guide like that. I would also appreciate a release of the unfinished version.
Earlier quoted context omitted.
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.
A C program starts at the function "main", what you're discussing here is beyond the scope of the C language. C without the libc or any other form of runtime is not standard C. I'm not trying to nitpick but I'm worried newcomers to the language might be misled by your comments, the things you're talking about are not a concern for most coders unless they have to do things like low level embedded code, bootloaders and…
I'd better not mention the IOCCC then.
Earlier quoted context omitted.
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?
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.
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). B…
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)
As part of broader reading it is deservedly a classic. Alone pretty terrifying.
Errors = safety nets are usually the main reason to make stiff learning curve. This would be a great help for them.
A minor point, but important to understand: the error came from the linker, not the compiler. It compiled just fine.
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?