Hacker News Reader

Comment by krat0sprakhar | Hacker News Reader

I've been programming in Python for a long time and recently took up an OS class which exclusively used C. Syntactic differences aside (declarations in C can get pretty hairy), the steepest learning curve while writing anything useful in C is with a) pointers and b) memory management which this guide doesn't seem to cover.

From my experience, the best way for learning C has been [0] Build Your Own Lisp and Zed Shaw's [1] Learn C The Hard Way.

That and of course spending countless hours debugging segfaults and memory leaks.

[0] - http://www.buildyourownlisp.com/

[1] - https://learncodethehardway.org/c/

View on HN

Uncommon and slightly extreme viewpoint: the best way for a python programmer to learn C is to learn a bit of assembly first.

Python is a high-level language: it provides tools to manipulate abstractions easily. C is a low-level one: it gives you access to chunks of memory (and far enough ropes to hang yourself while shooting yourself in the foot while drowning)

Assembly is not hard to learn. It has a reputation of being hard because it is tedious to use and that optimizations can be very intricate but learning basic assembly does not take long. Learn about MOV, ADD, JMP, INT, a few conditional jumps, learn how negative numbers are represented, what a memory mapping is, what a program counter or a stack counter are.

Then, go back to C. Read a bit about how function calls are made, memory allocated, and you will see that C is actually a high-level assembly language. All the hard parts of C will become obvious: a pointer is a variable that stores an address, a stack overflow, a segfault, a memory leak, all these will make sense very easily within that framework.

Completely agreed!

In the past, I had always avoided C because I didn't understand why many aspects of why it is the way that it is (eg pointers etc). Then I took my university's CPU architecture courses. That sorted that fear right out since I had to go from the ground up, learning everything I'd previously largely avoided or ignored - everything from transistors and the basic logic gates (AND, OR, XOR, NOT, etc) they consist of to full adders, all the way up to pipelined CPUs. Naturally, we learned assembly as part of this.

C made an awful lot more sense after all of this! I still don't like using it, but that's a lot more to do with my understanding of it's dangers (I prefer to let the compiler do the hard work of verifying my programs make sense, a la Rust &c), rather than a fear born of ignorance.

Alternatively write some basic constructs (loops, functions etc.) in C and inspect the generated assembly. You have to fiddle with compiler settings a bit because the optimized output isn't very helpful but for me it was extremely helpful to see what ASM code my compiler tool chain actually produces (to understand the typical function call structure for example).

Doing simple reverse engineering challenges is also a fun and easy way to get a patter matching kind of feeling for assembly.

>Uncommon and slightly extreme viewpoint: the best way for a python programmer to learn C is to learn a bit of assembly first.

I agree. I also sort of learned it that way. The difference was that I learned Turbo Pascal first, before C, and BASIC before TP, but then either while learning TP or C, I also learned some assembly and something about the fundamentals of computer hardware and microprocessors (as related to programming, not electronics) in an interleaved manner. Was lucky to have access to some very good books on all these (and many other topics) from the British Council Library in the city I was in at the time. Gave me a solid grounding in many topics related to computers.

This approach might lead to programmers thinking that they can do things in C because they have a particular mapping to assembly in mind. This might lead to undefined behavior. Casting pointers around for example is no problem in assembly (there are no types...) but has undefined behavior in many circumstances in C.

That doesn't mean that there is no defined behavior to achieve the same thing, though. Platform portability just requires a jump through a few more hoops and then some.

C is high-level language. It's portable across variety of platforms, while low-level languages are tied to hardware platform. Assembler is low level language.

Sounds very reasonable. Any specific books or tutorials you would recommend?

I personally found Programming From The Ground Up[0] to be phenomenal, though a little dated. Alternatively google around for NASM (or MASM if you're on windows) tutorials, such as asmtutor[1].

[0]: http://download.savannah.gnu.org/releases/pgubook/

[1]: http://asmtutor.com/

Any recommendations for assembly learning material?

Why not use LLVM IR instead, which is simpler?

From my experience in teaching C beginners, I think declarations are one of those things in C that people either get frustrated by very early on and give up, only memorising a small set of fixed patterns for the common cases; or see the pure elegance of the system, once it's presented to them in the right way. The two things to keep in mind to become one in that second group are "declaration follows use", and the operator precedence (array and function-call are on the right and have higher precedence than pointer indirection on the left.) Declarations must not be parsed left-to-right; in the same way that

    2 / 3 + 4 * 3

is not parsed left-to-right but as (2 / 3) + (4 * 3),

    int **foo[10];

is parsed as

    int *(*(foo[10]))

. What "declaration follows use" means is that the ultimate type of the object is exactly as it says after all the operators are applied (in the correct order): when the array subscript is applied to foo, and then that object dereferenced twice, the type of the expression is int. Thus foo is an array of 10 pointers to pointer to int, foo[i] a pointer to pointer to int, * foo[i] a pointer to int, and * * foo[i] an int.

http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html

If the system were elegant it wouldn't be quite so wildly inconsistent between prefix and suffix notation. "Middle-out" is not elegant.

I mean, I've been writing C for 20 years and would still prefer to break down a declaration with intermediate typedefs rather than write "pointer to function taking array of pointers to int-returning functions taking a void pointer, which returns a pointer to int-returning function taking a void pointer". If you can write that as a declaration right first time you can give yourself a serious pat on the back.

Challenge accepted, no cheating, no references, just editor and me. Hope that I got it right:

    int (*(*p)(int (*[])(void *)))(void *);

The process:

    ?which-returns (*p)( ?taking           )
                 ? (*p)( int (*[])(void *) )
             int (*(*p)( int (*[])(void *) ))(void *)

Testing with cdecl.org [1]:

    declare p as pointer to function [taking] (array of pointer to function (pointer to void)
     returning int) [, which] returning pointer to function (pointer to void) returning int

F-yeah. Can I has my pat? Seriously, it is not so hard if you used each component at least 100 times. That's few years of practice of non-hiding behind typedefs. You can't learn if you don't practice. (I'm not arguing that this should not be decomposed.)

[1] http://cdecl.ridiculousfish.com/?q=int+%28*%28*p%29%28int+%2...

IMHO pointers are mostly hard at the beginning because the asterisk-operator is overloaded: On one hand it declares (and optionally initializes) a pointer (type * x = ...;) and on the other it dereferences it (type y = * x;). At least for me that was the thing that puzzled me the most. I would prefer something like that:

  // declare and initialize x
  @uint32_t x = 42;

  // dereference x
  uint32_t y = ~x;

I.e. have different symbols for the type and the dereferencer ('@' and '~' as an example).

//edit: thanks for the help, fixed snippets - HN's parser does not get pointers either apparently :)

I've been programming C++ for too long to really understand why people find pointers hard, but I do remember that I did too at the beginning, and I do remember my epiphany (reading on the train, funny how I remember such senseless details 15 years later yet can't memorize a 4-item shopping list): given a declaration of

    struct Foo {
        int a;
    };
    Foo* f;

, the following two are equivalent:

    int b = f->a;

and

    int b = (*f).a;

Never had it spelled out for me like this, probably because it's so obvious once you get it - thought I'd share in case it gives anyone else an 'aha' moment.

The trick to teaching pointers is to model memory with boxes. You have a stack, and a heap, and you draw arrows to represent pointers. At some point, you need to reveal that those arrows are just numeric indices, but the visual helps early on. The * and & operators just let you follow the value in the pointer. I've had a number of students who were baffled up until I showed them this model.

Notational Machine for the win!

Back in the 80s the programming books I used always showed memory as little lines of boxes.

https://usborne.com/browse-books/features/computer-and-codin...

In general, thinking of memory as an array of bytes is helpful, and each byte has an address which is itself a series of bits that can be stored in memory --- and the concept that ties it all together and what I find makes a lot of people just "get it" is the fact that memory can itself store addresses that denote locations within it.

That's a perfect example of how knowing some assembly code helps with learning C.

i also had trouble with pointers while learning C, and, like everyone else, it seems so obvious now that i wonder what the hell my problem was. like learning to ride a bike, or drive a car with a manual transmission. i learned 8086 assembler before C and had no difficulty with indirection there.

for what its worth, your "aha" scenario would have just confused me more. even today, i have to think a bit before your second example makes sense to me.

You can consider them the "same" thing if you regard the asterisk as binding closer to the var instead of the type.

Which the declaration syntax hints at:

   int i, *p;

Can you elaborate?

My point is that the concepts "having a datatype, that stores an address" and "reading (typed) data stored at a specific address" are different, but share the same keyword (which is in this case just one symbol - maybe because C programmers have to use it often).

E.g. assuming C99's bool (0|1) datatype, you might define the "negate" functionality, which is often done by '!'. So we have something like that:

  // init a new bool
  bool success = 1;
  ...
  // negate the bool
  if (!success) {
    ...
  }

For me that makes sense. However if we take the pointer approach (as it is implemented), it would look like this:

  // init a new bool
  bool success = 1;
  ...
  // negate the bool
  if (bool success) {
    ...
  }

I hope this makes sense. For an experienced programmer * 's role is obvious from the context, but for me that was the most troubling concept when starting with C's pointers.

> My point is that the concepts "having a datatype, that stores an address" and "reading (typed) data stored at a specific address"

They are different things, but C's syntax was deliberately designed to imply the former from the latter. "Declaration reflects use" is the term they used for it.

The idea is that in something like:

    int *i;

You don't read it like, "Declare a variable 'i' whose type is 'int star', which is a pointer to an int". You read it like "declare variable 'i' whose type is such that taking 'star i' (i.e. doing a dereference) would give you an int". The type in this case is a pointer to an int.

This is always why function pointer syntax is so totally bizarre in C.

"Declaration reflects use" was a neat idea, but I think it practice it ended up causing more confusion than it solved. At the time, maybe they thought users would be tripped up by compound type expressions and thought it would help if they focused on the operations performed on the variable being declared.

In practice, it turns out that composed types don't seem to be that hard.

Wow this is really interesting, I did not know that, and it explains their choices. And C's function pointer types are indeed written in a bizarre way.

I definitely think of (int * i) as (i :: Ptr Integer) and (* i) in an expression like 42 + * i as (* :: Ptr Integer -> Integer).

Yeah, as long as we’re mixing notations, it’s really:

    *i :: Integer

From which you can conclude i :: Ptr Integer.

And the dereference operator does have the type you specified, but not in an lvalue—there the operator is really a mixfix one:

    (*_ = _) :: Ptr a -> a -> a

This isn’t specified directly by the standard, but follows from the rules about how an assignment operator must examine the structure of its first operand.

> In practice, it turns out that composed types don't seem to be that hard.

Depends on what you mean by hard. Hard to read or hard to reason about?

* -> * and * -> * -> * are easy to read and reason about, i.e. Int -> Char -> Int. But what about types of types?

(* -> * ) -> * is confusing to reason about IMO. i.e. Applicative Functors:

(<$>) :: Functor f => (a -> b) -> f a -> f b

Not really intuitive at all, the only reason I can understand it is that I know what functors and Monads are.

I'm not talking about higher-kinded types, just type annotations that are more than just a single bare identifier. Stuff like:

    List<int>
    (Some, Tuple, Type)
    Matrix[4][4]
    (Para, Meter) -> ReturnType

I'm probably misunderstanding you, but can I rephrase your comment as saying 'int i is the natural way of declaring a pointer to an int, and not int i'? Because if so, I don't recall that from the K&R (and I've read it front to back several times, not that that means much - I can't even remember if they use int* i or int *i, and I don't have my copy at hand here).

Alas, HN mangled your asterisks.

> I don't recall that from the K&R

I don't recall either, but this Wikipedia mention of "declaration reflects use" cites K&R:

https://en.wikipedia.org/wiki/C_%28programming_language%29#C...

Uh sorry, the first one had the asterisk next to the variable name, the other next to the type.

Yes I agree about the 'declaration reflects use'; what I meant was: does that imply that the declaration should consider the asterisk (the 'make this a pointer' part) to be 'part of', and thus right next to, the variable name or the type?

I'm strongly in the 'type' camp myself, and therefore I think that int *p; is nonsense; only to be used out of necessity when declaring multiple pointer variables on one line. So I'm wondering if 'declaration reflects use' reaffirms that, or contradicts it.

I don't see how the bool example follows; in what way is negating a boolean like dereferencing a pointer w/r/t types? ! is bool->bool; * is * P -> P.

The reason the same symbol is used is because of the way C types are read:

    int x; // (x) is an int
    int *x; // (*x) is an int
    int **x; // (**x) is an int
    int x(double); // (x(1.)) is an int

Yeah, sorry, my example sucks.

However, I am still believing a different operator would make more sense.

And what of [a-zA-Z0-9_]? Why should we allow them in both types and variables and functions? That's really confusing.

My elaboration is a bit late ... but.

    int i, *p;

Tells me that i is an int. And so is *p.

This had a way of always confusing me. For clarity, I'd declare them as:

  int i;
  int* p;

Think of it from the perspective of types:

    int *p; /* What is the type of p? Pointer to int */
    int a = *p; /* What is the type of *p? int */

I first learned pointers with Pascal and believe it was simpler with the ^ operator, but it has been so long I don't remember.

For some reason I also found pointer/references easy in Pascal, but struggle with them in C. I also find it easier to work with direct/indirect addressing in assembler than in C. I'm not entirely sure why - seemingly the differences between C and Pascal syntax and behavior for references seem trivial -- and yet somehow in Pascal it feels intuitive, while in C it feels complicated.

If I recall correctly (long long time ago) there was only one pointer type un Pascal and it was considered a number that it was legal to modify without warnings.

C insists that int * , char * and int are totally different types that you should not mix. It makes sense most of the time but it can be confusing when you do not realize that internally they typically are the same thing <insert here the disclaimer about 32/64 bits systems>.

I think it seems simpler because Pascal differentiates the type ^integer (“pointer to integer”) from the expression i^ (“dereference i”) and didn’t originally have an address-of operator—you could only get the address of a new anonymous value.

It's been so long, I don't really recall - but I was using object pascal which is fairly similar to free pascal:

http://www.freepascal.org/docs-html/ref/refse15.html

It's quite similar to c - yet I find it a little bit clearer.

For me the reason pointers were hard is because I didn't get clear feedback when I dereferenced them. When pointers are taught conceptually they don't tell you that there is a kernel terminating the program because you access invalid memory.

I confused that termination with the idea that my pointer has never been dereferenced in the first place. Now, I don't know if the kernel intervenes before the invalid address is going to be dereferenced or just after it. The thing is, I understood the concept, but getting this error was giving me doubt since I made an error of accessing valid memory.

Once I understood that I tried to force a normal int to become a pointer and eventually it worked (needed two ints and an 8-bit variable to cast it to a 64 bit address), proving to me that I understood the concept.

Accessing (valid) memory and pointers should be explained together.

I recall them being a way of seeing how much you studied at uni...or some professor wanting to bring up the morris worm

You may be interested in the SPECS design. They used a prefix ^ for this purpose.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34....

I agree, the notation was the hardest part of learning about pointers. Having a 'cheat sheet' - a program with examples of common ways of using pointers - helped me quite a bit.

I well remember that if how arrays decay to pointers was properly explained to me in the beginning, I would have "got" pointers a lot sooner

This exactly captures the struggle I've been having with pointers in Go - I have no problem grasping what a pointer is and how to use it, but I keep getting tripped up on the syntax because of exactly this.

I was about to tell you to escape it but I actually cant find a way to print an asterisk on HN

EDIT: you can print one by leaving a space after it: * aa

Yeah thx, I just realized that myself.

Do it like * this

I love Zed but I couldn't recommend Learn C the Hard Way to a beginner. The book starts out good, but then greatly ramps up complexity around chapter 17 (heap and stack memory allocation) without a good introduction to many new concepts, explanations are just completely missing. Most people I know who've all tried to go through the book ultimately start to lose interest and give up there unfortunately.

LCTHW is for absolute beginners. It lacks accuracy necessary for people writing C. It's good as an introduction, perhaps to capture interest, but no more than that.

"Stack" and "heap" are implementation details. I don't think the C standard mentions those words at all.

>> Syntactic differences aside (declarations in C can get pretty hairy), the steepest learning curve while writing anything useful in C is with a) pointers and b) memory management which this guide doesn't seem to cover.

Coincidently, I was making small talk at the office today with an undergrad (EE major) intern who's unenthusiastically taking a course in C programming to satisfy requirements. I told her that although those two points you brought up were precisely why traditional CS types generally hate/avoid C, it's imperative that she grasp these concepts as soon as possible (along with picking up an HDL) if a career in hardware floats her boat.

Coming from a formal hardware background myself--and ever so envious of the traditional CS types who were always hacking the wee hours away--I ended up picking up a used copy of Cormen and took some CS baby self-steps over a few semesters, using both Facebook Puzzles[1] and Project Euler[2] as a condom so it'd be much harder to become impregnated with my own bullshit. And yet, to this day, I still feel like a bag of suckass compared to our resident graybeards; last time I hacked some C was only a few months ago to make a JEDEC[3] interpreter that metaprograms source in an obscure, obsolete proprietary language, but I'm admittedly ashamed to share the source with anyone out of fear of affirmation that I still suck hind tit at C after all these years. ><

[1] https://web.archive.org/web/20091130184215/http://www.facebo...

[2] https://projecteuler.net/

[3] https://www.jedec.org/standards-documents/docs/jesd-3-c

I enjoyed K&R C, but I know it's a bit outdated - I was thinking of picking up a more modern C book.

Build Your Own Lisp implicitly claims you don't need to know Lisp to learn from the book:

> We will be covering many new concepts, and essentially learning two new programming languages at once.

Do you think that true? Did you know Lisp before reading it?

(I've done the first half or so of SICP so I know some Lisp.)

Right now I'm working on designing and implementing a virtual 16 bit CPU and an assembler, I guess the logical next step would be an OS class, then something like Build Your Own Lisp.

(For context, I write Python applications at work, but the work done by our embedded system C guys seems more interesting; I'm trying to learn enough C that I could be useful on one of their projects.)

A slightly more modern book that's a really excellent book to follow K&R is Hanson's C Interfaces and Implementations.

It's a book written in a literate programming style that describes how to build a flexible and modular library of data structures.

You will end up learning only that subset of lisp that this book implements. So this book is definitely as not overwhelming as it sounds.

In my case, I did know some lisp (Clojure) before starting out, but I'd strongly recommend that you don't hold back based only on that requirement.

I wrote a blog post that goes over pointers in C that may be useful:

https://drewdevault.com/2016/05/28/Understanding-pointers.ht...

It covers, but very slightly (see below, I skimmed it exactly to look for it). My observation is that this is really hard for many people. I helped couple of my course mates with background mainly in Python and this was the only thing they struggled with, and they struggled hard. It forces you to be very observant and conscious about the situation. Until you get that far, you will continue to suffer. C is really unforgiving.

Every once in a while, you'll see a C program crash, with a message like “segmentation fault” or "bus error.” It won't helpfully include any indication of what part of the program is at fault: all you get is those those two words. Such errors usually mean that the program attempted to access an invalid memory location. This may indicate an attempt to access an invalid array index, but typically the index needs to be pretty far out of bounds for this to occur. (It often instead indicates an attempt to reference an uninitialized pointer or a NULL pointer, which we'll discuss later.)"

As always, I recommend valgrind.

  $ gcc -Wall -g prog.c -o prog
  $ valgrind ./prog
  ...
  ==25494== Process terminating with default action of signal 11 (SIGSEGV)
  ==25494==  Access not within mapped region at address 0x0
  ==25494==    at 0x400532: main (prog.c:5)
  ==25494==  If you believe this happened [...]
  ...
  $

This helps a lot while debugging. Note that it is also helpful when debugging memory leaks and can give you the exact line in your code where you issued alloc() that you did not free later.

Very cool, this would help a lot indeed.

Are there other such tools a casual C programmer should be aware of?

Turn on all compiler warnings (-Weverything for Clang and RTFM for GCC (no, -Wall doesn't turn all the warnings on)).

Scanbuild (LLVM based, Linux and macOS)

Perf (recent Linux) or DTrace (macOS, SmartOS, Solaris and FreeBSD)

Valgrind (Linux, macOS) with the KCacheGrind/QCacheGrind (CPU usage), Valkyrie (leaks and undefined behavior) and Massif-visualizer (memory usage) GUIs

The compiler sanitizers (GCC, LLVM, Linux and macOS)

strace (Linux)

HeapTrack (Linux, a true hidden gem, best memory profiler ever)

Binutils (Linux, macOS)

And really, get to know your debugger. Both GDB and the Visual studio debugger are extremely powerful. If you think a debugger does beakpoints and nothing else, you really, really need to get to know your debugger better. LLDB is getting there too, it will catch up soon (surprising given how long it took the other 2 to mature).

For people from a Python background, know that both GDB and LLDB are available as a Python shell with full access to the C program internal. You can add triggers to execute Python callbacks, conditional breakpoints and even gather stat and have them display in MathPlotLib or iPython Notebook.

Any good references to gathering stats using debugger and visualizing with Python?

Good luck finding anything. It is in many performance ninjas arsenal, but very little documented. Here is an untested mix of some other scripts that might less or more almost work. At least it can get you started:

https://gist.github.com/Elv13/48b43ead347faba1b59378267d2364...

Yes, there are gazillions of useful tools, but another important point is that C is tightly coupled to *nix systems and the best platform to develop C is definitely a Linux-based system (ignoring embedded systems for the meantime, where C also shines), as otherwise most quality information that you find in the interwebs won't work for you.

This has changed since 2011. Both GCC and LLVM/Clang support

export CFLAGS="-ggdb -fsanitize=address"

And few other "sanitizers". They add a runtime to the binary so you get the backtrace, detect runtime "silent" errors (undefined behaviors) and overall help develop C/C++ programs.

Surprised you didn't try C++ if you found C quite difficult. C++ teaches memory management but without the insanity level dialed to 11 like with C (or more so with Assembly).

I've always discouraged learning Python first. Python disconnects you so much from what is really going on and does so much for you that you don't develop algorithm and conceptual skills and computer knowledge.

All the developers where I'm at, from SQL to Python, Node to Angular, everyone, all say the same thing about Python and other "hyper-package-assisted" languages.

> That and of course spending countless hours debugging segfaults and memory leaks.

Maybe that's because you think that:

> the best way for learning C has been [0] Build Your Own Lisp and Zed Shaw's [1] Learn C The Hard Way.

Care to be more specific about what you mean? What would be your preferred way of learning C?

Really, how can you get proficient at programming C without spending countless hours debugging segfaults and memory leaks?!

The resources you refer to are abysmal, criticism is available and widespread online if you want details.

You get proficient at C programming by properly understanding what you learn rather than spend countless hours in trial and error cycles.

There isn't much magic to it and the concepts are quite simple. In my opinion if you're looking to get up to speed quickly instead of carefully writing code then C is not for you.

To be honest I learned from K&R but I guess it's too outdated and not really about "modern C". But of those resources one of them seemed quite fun and probably harmless ([0]) and the other one ([1]) pretty practical and "bad style" but error-free as far as I read through it, with the added benefit of teaching newbs that tools matter a lot and getting them pretty fast into using make, valgrind etc....

In your opinion, what would be:

1. the modern equivalent of K&R?

2. a solid reference to keep around and consult afterwards?

(with 1 and only 1 answer to the questions above, please, not a list, 'cause every time I search "learn c" I get over lists upon lists, of high quality comments - which is bad because you can't actually dismiss them as rubish, you actually have to read them -, that only throw you into paralysis by analysis, so you just say, "fuck it, just grab K&R or LCTHW, then grab a C open source project you feel like hacking on and start banging you head on it"...)

1. For "modern C" it would be K&R, then learn Haskell; especially take note of its type system and how you can apply what you learn there in C.

2. The C standard draft, your compiler(s') manual and man pages if you're on POSIX. Also pencil and paper for drawing your arrays.

Clarification about 1: Haskell has good solutions to a lot of problems that have plagued programming, learn them because they are not language-specific but are mindset-specific. The advantage is that once your mindset changes, you start paying attention to off-by-one errors and potential overflows and overruns. You also start paying attention to using the correct types in a C program and you start taking advantage of enums to reduce the space of possible states in each function in your program. Once this clicks, memory management is a breeze.

Also learn the mindset of solving the problem at hand and nothing but the problem at hand. C is not a language for creating abstractions everywhere, it's a language for writing down as little steps as possible to solve that specific problem.

This ^

Syntax and data structures are usually the easiest part of learning a new language. Leveraging implicit conventions and trying to build anything useful is much harder.

This is still a useful reference for anyone looking to jump into C.

I understand pointers pretty well, having programmed them in TTL logic, assembly language, Pascal, and BASIC (via PEEK and POKE). Python is a relative newcomer to my tool chain.

What confuses me about pointers in C is simply the syntax, and I'm sure it's because I just don't write enough C to be able to read it with any kind of fluency. I find C programs to be harder to read than any other language that I'm regularly in contact with. Of course this could be because of what C is used for.

Both of these are listed under "Stuff that should be avoided" here http://www.iso-9899.info/wiki/Main_Page#Stuff_that_should_be...

Use the address sanitizer and valgrind on your tests and you'll keep your sanity.

Thanks for this. I've failed C courses in university and in MOOCs when things get to pointers.

In your opinion, did learning C make you a better programmer in Python?

Just knowing C probably not, but knowing how PHP is implemented internally did make me write PHP differently; and I suspect the same would be true for any scripting language.

(for example being much more conscious about pass by reference, the cost of various functions, the overhead of calling functions and doing data conversions etc).

That's why you shouldn't put anything on the heap in C.

Reply on news.ycombinator.com