struct calculate_args {
        int x, y;
        enum {add=0, sub} operator;
    };

    int calculate_func(struct calculate_args args) {
        if (args.operator == add)
            return args.x + args.y;
        else
            return args.x - args.y;
    }

    #define calculate(...) calculate_func((struct calculate_args){__VA_ARGS__})

    calculate(1, 3); // 4
    calculate(8, 3, .operator=sub); // 5
    calculate(.operator=sub, .y=7); // -7

    #include <stdio.h>
    #define CONCAT2(a, b) a##b
    #define CONCAT(a, b) CONCAT2(a, b)
    #define COUNT_ARGS2(a0, a1, a2, a3, a4, a5, a6, a7, a8, N, ...) N
    #define COUNT_ARGS(...) COUNT_ARGS2(__VA_ARGS__, 9, 8, 7, 6, 5, 4, 3, 2, 1)
    #define foo(...) CONCAT(foo_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)

    void foo_1(const char *a){
        printf("one arg: %s\n", a);
    }

    void foo_2(int a, int b){
        printf("two args: %i and %i\n", a, b);
    }

    int main(){
        foo("asdf");
        foo(314159, 271828);
    }

    *outArg = myPtr; myPtr = NULL;
    free(aPtr); aPtr = NULL;

Some people say they like dangling pointers because they want their program to crash if something is freed when they don't expect it to be. Good! Do this:

    assert(ptr);

Please, null out your pointers and stop writing (most) use-after-free bugs!

#define ZFREE(p) do { free(p); p = NULL; } while(0)

  #define free(p) do { free(p); p = NULL; } while(0)

  (free)(p);

    if(x) MACRO();
    else something();

    if(x) { ... }; // Error!
    else something();

    #define FREE(ptrptr) do { \
        __typeof__(ptrptr) const __x = (ptrptr); \
        free(*__x); *__x = NULL; \
    } while(0)

Edit to add: I've honestly been moving away from using a macro and just putting both statements on one line like in the OP. For something so simple, using a macro seems like overkill.

    int* p = malloc(sizeof(int));
    FREE(&p);

    #define FREE(ptr) do { \
        __typeof__(ptr)* const __x = &(ptr); \
        free(*__x); *__x = NULL; \
    } while(0)

    int* p = malloc(sizeof(int));
    FREE(p);

Maybe someone else could figure out how to do it properly, since I'd definitely prefer a function.

The trick of checking that buffers are zeroed is purely a debugging tool, so it's okay if it doesn't work on some platforms. And if you allocate with calloc(), the padding will be zeroed for you. It's actually very rare that you will have to call memset() with this technique.

This is like the most clichéd way of saying “my code has security vulnerabilities” that there is. I have yet to see code that has remained secure solely on the “discipline” of programmers remembering to check things.

> The trick of checking that buffers are zeroed is purely a debugging tool, so it's okay if it doesn't work on some platforms.

Fair.

> And if you allocate with calloc(), the padding will be zeroed for you.

It might get unzeroed if you work with the memory.

Also, it's not just about vulns in security-critical code. It's also about ordinary bugs. Why not be a little more careful? It won't hurt.

> It might get unzeroed if you work with the memory.

Maybe, but it isn't very common. I'm not sure when the C standard allows changing padding bytes, but in practice the compilers I've used don't seem to do it. And again, it's just a debugging aid, if it causes too much trouble on some platform, just turn it off.

If the extra code is really that bothersome, just use a macro or wrapper function.

  $ clang -x c -
  #include <stdlib.h>
  
  int main(int argc, char **argv) {
      char *foo = malloc(10);
      free(foo);
      free(foo);
  }
  $ ./a.out
  a.out(14391,0x1024dfd40) malloc: *** error for object 0x11fe06a30: pointer being freed was not allocated
  a.out(14391,0x1024dfd40) malloc: *** set a breakpoint in malloc_error_break to debug
  Abort trap

1. advocating adding additional code, which has historically been hard to actually do in practice, and

2. providing a suggestion that is generally worse.

I can see an argument for wrapping it in a macro so you can turn off nulling in debug builds (ASan might even have hooks so you can automate this, I know Valgrind does). But use-after-free is worse than just double-frees, and if you read a dangling pointer in production there's no real way to catch it AFAIK. Last I heard (admittedly been a few years since I checked), you're not supposed to deploy ASan builds because they actually increase the attack surface.

So, your program's memory is full of these dangling pointers, and at some point you will have a bug you didn't catch and use one. And you can't even write an assertion to check that it's valid. What do you propose?

And again to clarify, I'm not trying to advocate for hiding bugs. I want to catch them early (e.g. with assertions), but I also want to avoid reading garbage at runtime at all costs, because that's how programs get pwn'd.

From an exploitability point of view they are largely equivalent.

As for the rest of your comment: my point of view is largely "you should catch these with Address Sanitizer in debug", so I don't usually write code like "I should assert if I marked this as freed by NULLing it out". If I actually need to check this for program logic, then of course I'll add something like this.

The macro you suggest would alleviate my concerns, I suppose, and it wouldn't really be fair for me to shoot that solution down solely because I personally don't like these kinds of assertions in production. So it's not a bad option by any means, other than my top-level comment of this requiring extra code. I know some libraries like to take a pointer-to-a-pointer so they can NULL it out for you, so that is an option for your wrapper. And a double-free that doesn't crash can sometimes open up exploitable bugs too since it messes with program invariants that you didn't expect. But these are much rarer than the typical "attacker controlled uninitialized memory ended up where it shouldn't" so it's not a big deal.

That's not what the parent comment said.

Is that a real issue, though?

> padding is going to make your life annoying

Just memset?

> Is that a real issue, though?

Of course, it's not, but that's one of those factoids that everyone learns at some point and feels like needing to rub it into everyone else's face assuming that these poor schmucks are as oblivious to it as they once were. A circle of life and all that.

[0] https://reviews.llvm.org/D26196

https://llvm.org/docs/AMDGPUUsage.html#address-spaces

Do you use sanitizers for use-after free bugs? I see many people still don’t use them even though sanitizers have become very good in the last 5-6 years

I use every tool at my disposal. Sanitizers, static analyzers... and also not leaving dangling pointers in the first place. Why would I do anything less? It doesn't cost anything except a little effort.

Take a look at this recent HN link: https://www.radsix.com/dashboard1/ . Look at all those use-after-free bugs. Even if it only happens 1% or 0.01% of the time... It's a huge class of bugs in C code. Why not take such a simple step?

As an added benefit the code also becomes more robust in the production environment, if there are use cases you failed to consider -- 100% branch coverage does not guarantee that there are none!

Whole heartedly agree.

> If a program fails to compile or quickly crashes (because of a failed assertion), then I consider that better than having to unit test and fuzz test your code to find that particular problem.

This confuses me. My typical order would be:

fails to compile > unit test > quick crash at runtime > slow crash at runtime (fuzzing)

I am curious to understand why we differ there.

But I'll also say that if you don't have any use-after-free bugs in the history of a large C codebase... you might not even be on the lookout for them? I still have them sometimes, mainly when it comes to multiple ownership. And those are just the ones I found eventually.

So yes, different strokes for different folks, but if you make the effort to incorporate tricks like this into your "unconscious" coding style, the ongoing effort is pretty minimal. Even if you decide this trick isn't worth it, there are countless others that you might find worthwhile. I'm always on the lookout for better ways of doing things.

  #ifndef __clang__
  #define assume(expr) \
      __extension__ ({ \
          static_assert(__builtin_choose_expr( \
              __builtin_constant_p(expr), expr, true), #expr); \
          assert(__builtin_choose_expr( \
              __builtin_constant_p(expr), true, expr)); \
      })
  #else
  #define assume(expr) \
      __extension__ ({ \
          static_assert(__builtin_constant_p(expr) ? (expr) : true, #expr); \
          assert(__builtin_choose_expr( \
              __builtin_constant_p(expr), true, expr)); \
      })
  #endif

I also like to use __auto_type very much:

  #define var __auto_type
  #define let __auto_type const

  #define m_max(a, b) \
      __extension__ ({ \
          let _a = (a); \
          let _b = (b); \
          _a > _b ? _a : _b; \
      })

And in case anyone else is wondering, the advantage of that m_max macro is that it evaluates each of its arguments only once.

    static struct {
        int a;
        float b;
        const char* c;
        struct {
            float x, y, z;
        } nested;
    } state = {
        .a = 1,
        .b = 2.0f,
        .c = "Hello World!",
        .nested = {
            .x = 1.0f, .z = 3.0f
        },
    };

    static struct {
        const char *key;
        const char *value;
    } elems[] = {
        { "k1", "v1" },
        { "k2", "v2" },
        { "k3", "v3" }
    };
    for (int i=0; i<sizeof(elems)/sizeof(*elems); i++) {
        printf("%s => %s\n", elems[i].key, elems[i].value);
    }

https://blog.gboards.ca/2020/02/adventures-in-obscure-c-feat...

https://en.m.wikipedia.org/wiki/X_Macro

  > The best C programming trick is to use no tricks.

The very notion of there being tricks and that knowing them makes you better is something I hate about C and C++. Most tricks I read here are bandaids over usability issues the languages have. Yes, they alleviate an issue but may introduce unexpected consequences and distance your dialect from the rest of the community.

I am so very thankful that C and C++ are no longer the only options for low level, non garbage collected programming.

E.g. this is 'named, optional arguments East Egg' is a useful trick which also improves readability:

    my_func((my_struct) { .bla = 1, .blub = 2, });

    typedef struct pixel {
        int r;
        int g;
        int b;
    } pixel_t;

    #define PIXEL(red, green, blue) \
    (pixel_t)                       \
    {                               \
      .r = (red),                   \
      .g = (green),                 \
      .b = (blue)
    }

    void display_pixel(pixel_t pixel);

    display_pixel(PIXEL(255, 255, 255));

    return PIXEL(255, 255, 255);

    display_pixel((pixel_t) {.r = 255, .g = 255, .b = 255});

The compatibility with the C library is up to C11 for example.

Google even sponsored a massive effort to clean the Linux kernel of their use.

A subset of designated initializers is supported in C++20.

It's interesting that the other C descendant Objective-C has decided to "respect" its C subset instead of messing with it, with the result that new C standards are automatically supported in ObjC.

Took them only 21 years... And this standard being so recent, most projects won't have that for years to come.

https://godbolt.org/z/GW59rM

In your example,

    Point point = {.z = 2.0, .x = 1.0};

Effectively generators a la python or javascript, implemented using a set of macros that expand to a Duff's device control structure.

    #define crBegin(state) \
        int *__state_ptr__ = &(state); \
        *__state_ptr__ = 0; \
        switch(*__state_ptr__) { case 0:
    #define yield(x) \
        do { \
            *__state_ptr__ = __LINE__; \
            return x; \
            case __LINE__:; \
        } while (0)
    #define crFinish }
    
    struct counter_frame {
        int state;
        int i;
    };
    
    int counter(struct counter_frame *frame) {
        crBegin(frame->state);
        frame->i = 0;
        while (1) {
            yield(frame->i++);
        }
        crFinish;
    }
    
    int main() {
        struct counter_frame my_counter;
        while (1) {
            printf("%d\n", counter(&my_counter));
        }
        return 0;
    }

  /* Return the offset of 'member' relative to the beginning of a struct type */
  #define offsetof(type, member)  ((size_t) (&((type*)0)->member))
  
  #define container_of(ptr, type, member) \
   ((type *)((char *)(ptr) - offsetof(type, member)))

Still interesting to see the trick behind it tho.

The way it's used is that Ganesha supports defining of alternate filesystem backends and serving them as NFS shares. Handles to objects (e.g. files) would exist as pointers which live inside the struct of the backend's handle struct. i.e.:

  struct my_file_data {
    struct ganesha_file_data {
      // generic data
    };

    // data specific to my module
  };

This really helps whipping people into shape and making them pay attention to what they write. Also helps documenting the code in a very succinct way.

You can also print backtraces when an assertion fails: https://stackoverflow.com/questions/77005/how-to-automatical...

(Whether you should use assert for that kind of checks that probably only should run in tests is debatable, but it sometimes happens)

  switch (...) {
    case A:
      ...
    case B:
      ...
    ...
    default: // all possible cases are dealt with above
      assert(0);
  }

    assert(!"You gave an invalid letter");

https://github.com/nothings/stb/blob/master/stretchy_buffer....

This basically allows you to use std::vector<T> like vectors in C, but with an added benefit that you can subscript the vector like arr[3] rather than using unwieldly functions like vector_get(arr, 3) or vector_put(arr, 3, value).

    foo();
    //*
    some();
    code();
    which_you_want_to_comment_out();
    // */
    other_code();

A lot of the rest of these look like they’re just trying to be clever for the sake of it.

  /** /
  do_thing();
  /*/
  do_other();
  //*/

This is from APUE, 3rd Edition.

  void (*signal(int signo, void (*func)(int)))(int);

  typedef void Sigfunc(int);
  Sigfunc *signal(int, Sigfunc *);

  __attribute__((cleanup(cleanup_function)))

1. https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Variabl...

    debug && printf("counter: %d\n", i);

Example with 3 "values". This is the base definition from which all the tables and enums are produced.

  #define FOREACH_LAN(LAN)\
    LAN(GA, IE, C_ANSI    )  /**< Irish Gaelic   :  0 */ \
    LAN(DE, DE, C_ANSI    )  /**< German         :  1 */ \
    LAN(DA, DA, C_ANSI    )  /**< Danish         :  2 */ \
    LAN(EL, EL, C_GREEK   )  /**< Greek          :  3 */ \
    LAN(EN, GB, C_ANSI    )  /**< English        :  4 */ \
    LAN(ES, ES, C_ANSI    )  /**< Spanish        :  5 */ 
   etc.

    #define GENERATE_LANIDX(lan,country,codepage) LANIDX_ ## lan,

    typedef enum {
      LANIDX_UNDEFINED = -1,        // 
      
    FOREACH_LAN(GENERATE_LANIDX)  

      LANIDX_MAX                    // Automatically get the upper bound
    } LANIDX_TYPE;

    typedef enum {
      LANIDX_UNDEFINED = -1,        // 
      LANIDX_GA,      
      LANIDX_DE,      
      LANIDX_DA,      
      LANIDX_EL,      
      LANIDX_EN,      
      LANIDX_ES,      
      LANIDX_MAX                    // Automatically get the upper bound
    } LANIDX_TYPE;

Now in the module I can define tables, also without needing to repeat the codes

   const char *LanIdx2LanTable[] = {
    #define GENERATE_LANIDDX_2_LAN(lan,country,codepage)  [1+ LANIDX_ ## lan]={#lan},
    FOREACH_LAN(GENERATE_LANIDDX_2_LAN)
   };

   const char *LanIdx2CodePageTable[] = {
     #define GENERATE_LANCP(lan,country,codepage)  [1+LANIDX_ ## lan]=codepage,
     FOREACH_LAN(GENERATE_LANCP)
   };

int x = 10;

while (x --> 0);

  for(size_t i=N; i-- > 0 ;) do_stuff_with(&a[i]);

  if (turn_on() || reset(), turn_on()) {  // try to turn it on. if fail, reset and try again
    // it's on
  }

It's always going to try again, though, even if successful the first time. Perhaps you forgot parentheses?

  if (turn_on() || (reset(), turn_on()))

    #ifdef _DEBUG
    #define __REVIEW_ME      / ## / 
    #else
    #define __REVIEW_ME      $review_me$
    #endif

This also allows adding free form comments if needed:

    foo += 13;    __REVIEW_ME -- why 13 ?!

2011 https://news.ycombinator.com/item?id=3110846

   typedef bool foo_fn(int, char);

   foo_fn  foo1, foo2, foo3, foo4;

   bool foo1(int, char);
   bool foo2(int, char);
   bool foo3(int, char);
   bool foo4(int, char);

   void function_taking_foo(int, foo_fn *);

   function_taking_foo(1, foo1);   // no cast necessary as type is identical and even

   function_taking_foo(1, (bool(*)(int,char))foo1);

#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))

2. Not strictly C: using `pahole` to analyze how structs are laid out in memory

https://linux.die.net/man/1/pahole

My favorite "programming" trick only applies if I'm not sharing my code. I just forego header files entirely, and just #include the .c source files. Also, put `#pragma once` in all the .c files to avoid double-inclusion without the hassle of #if ... etc. This requires a bit more diligence since you can't have mutual recursion between source files.

    struct foo { int a, b; };

    void pr(struct foo *n) { printf("%d %d\n", n->a, n->b); }

    struct foo p;
    p.a = 1;  // Yuck!
    pr(&p); // Bad!

    struct foo p[1];
    p->a = 1; // Very nice..
    pr(p); // Yes!

Anyway it means you can't cut and paste code from one place to another without changing '.' to '->' or vice-versa.

E.g. a:

int x = a->b->c->d;

means there's 3 memory accesses, while

int x = a.b.c.d;

means there's one memory access for the whole expression.

Also consider this:

int x = a->b.c->d;

I can immediately see where pointer indirections are happening.

...unless you're in C++ of course which messed up this simple rule when references were added to the language.

It's not true if the compiler can figure out that the left side is a constant, consider:

    struct foo { int a; };
    struct foo z = { 7 };
    struct foo *const p = &z;

    int fred() { return p->a; }

    fred:
        movl    z(%rip), %eax
        ret

    p:
        .quad   z

    z:
        .long   7

A chain of '.' on the other hand is always guaranteed to be resolved into a single offset at compile time.

Because using `(*ptr).member` everywhere is annoying. There's plenty of times you want or need to have direct access to a member rather than always dereferencing a pointer.

Here's a variation that seems plausible: make postfix p^ be like C's p[0], and infix p^i like C's p[i]. (With a tighter binding for ^ than C has.)

https://github.com/ekmett/lens/wiki/Examples

> ("hello","world")^._2

  switch (fruit) {
    case APPLE:
      if (true) {
        pick_apple();
      } else
    case BANANA:
      {
        pick_banana();
      }
      box_fruit();
  }

An example of where this matter is an AST forest, like this:

    struct node { int tag; }; // Generic node
    struct infixnode { int tag; struct node *l, *r; };
    struct intnode { int tag; int val; };

    struct node *n;
    int d = ((struct intnode *)(((struct infixnode *)(((struct infixnode *)(((struct infixnode *)(((struct infixnode *)n)->r))->r)))))->val;

    union node { struct infixnode infix; struct floatnode floatval; struct intnode intval; };

    union node *n;
    int val = n->infix.r->infix.r->infix.r->intval.val;

    node *n;
    int val = n->infix()->r->infix()->r->infix()->r->intval()->val;

Definitely not exhaustive as this thread though.

[1] https://ne02ptzero.me/blog/c-tricks-that-i-use-everyday.html

One might argue it’s not even C..

Also, anything involving arrays of pointers to functions is cool by definition.

People might like it or not, but SO is a tool that provides fast access to answers on technical questions because people want to solve their problems(and learn), it's QA.

If you want to discuss stuff then there are forums, reddits, discords or even HN.

struct foo star p = malloc(sizeof (struct foo) + 100); p->b[50] = 'x';

A conventional and working form of the same is

     struct foo { int a; char b[1]; }
     struct foo * p = malloc(sizeof (struct foo) + 99); 
     p->b[50] = 'x';

     struct foo { int a; char b[0]; }
     struct foo * p = malloc(sizeof (struct foo) + 100); 
     p->b[50] = 'x';

Edit: it's UB because you're accessing past the end of an array with size given at compile time.

    struct foo { int a; char *b; }
    struct foo *p = malloc(sizeof (struct foo) + 100);
    p->b[50] = 'x'; 
    ...
    free(p);

  Test