[irundebian]

I'm not sure that you avoid errors by forcing yourself to write short code. With C macros.

[loup-vaillant]

Here's a real world example:

https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a...

So I have this function, `crypto_wipe()` that wipes memory regions with `volatile` so the compiler doesn't optimises it away. In the link above I was using it thus:

  crypto_stuff(stuff_ctx *ctx) {
      // stuff
      crypto_wipe(ctx, sizeof(ctx)); // BUUUG!!
  }

See the bug? I should have dereferenced `ctx` in the sizeof operator. As it was, was only wiping a pointer's worth of data instead of the whole structure. Oops.

Now I write this instead:

  crypto_stuff(stuff_ctx *ctx) {
      // stuff
      WIPE_CTX(ctx); // correct!
  }

The amount of repetition I avoid this way is almost negligible, but that was enough to trigger a mistake (I had quite a lot of wiping to do). With the macro, errors are much easier to spot (so much so that I am willing to give 100€ to anyone who finds such an error, see https://monocypher.org/quality-assurance/bug-bounty)

[irundebian]

In this case the use of macros may increase the readability or assurance of the code, still there are a lot of cases where macros can easily lead to bugs: https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pa...

[loup-vaillant]

Of course. You will note I only went macro to prevent an error I already made. C macros suck, I don't use them lightly.

[yodsanklai]

When you write "FOR(i,n)", instead of "for (int i = 0; i < n; i++)" you only write "i" once instead of 3, which makes it less likely to make mistakes.

That being said, I've found that competitive programmers sometimes write extremely ugly code. It's surprising to see how they are able to solve such complex problems, and yet can't (or don't value) write readable and structured code. Maybe they are so sharp that they don't feel the need to make their code more readable.

[kevmo314]

Well, when your code has a lifetime of five hours max, readable doesn't matter, correct does.