Cool C Programming

  #define CHECK(X, Y) \
  do { printf("Performing Assertion\n"); assert((X - Y) != 0); \
  printf("Assertion passed\n"); } while (0)

It's OK when you are doing subtraction, but if you were doing something like division or multiplication, you could screw with the order of operations if you don't do this.

So much of this stuff is the kind of thing people new to C should not be doing. Minimizing use of preprocessor directives leads to more maintainable C. Use them where they are needed and not anywhere else.

Also, for the swapping they show:

  a = a ^ b;
  b = a ^ b;
  a = a ^ b;

  int tmp = a; //or: register int tmp = a;
  a = b;
  b = tmp;

  double array[SIZE][SIZE] = {
      #include "float_values.txt"
  }

There are so many gotchas with writing good quality, safe macros and they're also not well handled by many tools. E.g. my IDE is pretty hopeless at following complex macros.

We've got better alternatives today. Unit testing is probably the first one everyone thinks of but i reckon switching to a graphical debugger (i used to only use CLI gdb) also reduced my need for these kind of hacks.

I feel like this article should be named "C's naughty bits", e.g. the array indexing in #7.

There are some good ones though, i like the idea of better separating code and data per #15.

Hope you enjoyed it! Thanks!

  Feature/Trick #4 :

  #ifndef FILE_H
  #define FILE_H
   ...
  #endif

1) Name variables in macro differently (e.g. _X instead of just X) and always use them in parentheses.

2) Always initialize pointers, especially in examples for beginners, as segmentation fault while stepping on uninitialized or dangling pointer is one of the most common errors I have seen.

3) Using -Wall compiler directive is also a good idea to see many possible problems you could miss otherwise.

4) Trick #15 is a really bad practice, it's way better to include header file that declares and defines array, something like Gimp or OpenSSL do when you choose to export output as a header file.

5) Just a suggestion: there is a very handy macro for debugging worth mentioning:

    #ifdef DEBUG
    #define DBG(fmt, ...) \
        printf("%s: " fmt, __func__, ## __VA_ARGS__)
    #else
    #define DBG(fmt, ...)
    #endif

  #include <stdio.h>

  #define atoa(x) #x

  #define mdb(x) printf("%s\n", atoa(x))

  #define swap(type, x, y) do {type temp = *(x); *(x) = *(y); *(y) = temp;} while(0)

  int main(int argc, char *argv[])

  {

    int cat[2] = {33, 44};

    printf("atoa(cat): %s\n", atoa(cat)); // "cat" 
	
    mdb(swap(int, cat, cat+1)); // expands the macro inside to text 
	
    swap(int, cat, cat+1); // the macro itself 
	
    printf("cat[0]: %d\n", cat[0]); // 44 
	
    return 0;
  }

    #define dbg(...) fprintf(stderr, __VA_ARGS__)

Although, it does point out some interesting idioms of the language and I agree that scanf is bloody cool. IMO every language should have printf/scanf equivalents :o)

Actually, anything involving meta-programming is "cool". Knowing a language is "easy" once you get the logic, but manipulating the language to do the work for you is even more satisfying.

  char* first_name; int age;

  fscanf(fptr, "%s %d", first_name, &age);
  printf("Name: %s\nAge: %d\n\n", first_name, age);

(Sorry about the snarky tone, I just wanted to use that meme because it's appropriate.)

About the debugging macros: printf prints messages to stdout, not stderr. You want to use fprintf instead:

  fprintf(stderr ,"error message");

although i do think __ FUNCSIG __ deserves a mention along with __FILE__ and __LINE__ :)