Principles for C programming

Can someone explain this sentiment to me? I know about licensing and philosophical criticisms, but are there any _technical_ faults?

> Don't use macros.

> Don't use the inline keyword

> Never put code into a header

I disagree with these. It's often critical to avoid a function call in hot paths, and if you don't use macros or inline you have to resort to copy/paste, which is error-prone and hampers maintainability.

It's also the case that C is a rather inflexible language. Macros can be extraordinarily helpful in reducing boilerplate: in unit testing, for example. I won't argue that macro definitions are the easiest things to read (usually they're OK but they can get pretty arcane), but I do think something that cuts a file down from 8,000 lines to 1,000 is at least worth considering.

Macros can also help you maintain type safety. Colin Perciva demonstrated this a little with his elasticarray, but khash is another example of using macros to dynamically create type safe data structures. It can also help the compiler optimize your code.

> Don't use fixed-size buffers

Everything is a fixed-size buffer until you change its size. If you malloc a buffer of 1024 bytes and read 1025 bytes of user input into it, you overflowed anyway. The principle ought to be "check your bounds", which applies whether your buffer is stack/heap.

> Do not use a typedef to hide a pointer or avoid writing “struct”.

I'm with you on pointer hiding (looking at you FreeType), but "struct" is just far too verbose. You don't accidentally pass things by value because the compiler will tell you you're passing the wrong type. You won't think it's actually a scalar because you have a grand total of 3 scalars in C (bool/int/float), and if you don't know the types you're working with in your functions you should probably look them up.

You probably don't think this is a big issue because you don't adhere to 80 columns in your code (I looked @ your GitHub briefly), but let me tell you you run out of space real quick, and "struct" is practically meaningless.

I found a good example:

  static void set_background(struct wl_client *client, struct wl_resource *resource,
  		struct wl_resource *_output, struct wl_resource *surface) {

  static void set_background(wl_client *client, wl_resource *resource,
                                                wl_resource *_output,
                                                wl_resource *surface) {

> GNU is a blight on this Earth

Come on now. I hate GNU indentation as much as any reasonable person, but I don't think we need to go this far.

---

Unrelated: aerc looks great! I've been thinking about moving off gmail and moving more of my life back into the terminal (I used to be all mutt and IRC and now I'm gmail and hangouts :/ ), and I really like aerc's well-organized code. Nice work.

And then suddenly you're on a different platform and discover that you can't rely on that -- pretty bad if it's in a central part of your system (like trampolining functions for your toy lisp).

On the other hand, you might run into the same issues if the standard support is sub par. People used to declare K&R-style functions for ages after ANSI was passed, and I wouldn't bet a central part of my system on C99.

I thought the author also implied that GNU was technologically inferior and/or problematic. That would interest me...

Not niche at all. You should have a range check on pretty much every value you accept from a command-line option.