What must a C macro do to be a valid answer?

Question

Recently, an answer of Peter Taylor here says:

To get a macro equivalent to

f(n){n=n?:1;}

you need

-Df(n)=((n)?:1)

which is longer, so there's no point.

So are those criteria really necessary? Which of the following criteria should be satisfied:

• Arguments must be put in parentheses.
• The function itself must be wrapped in parentheses (unless it's single token).
• The argument must be referenced exactly once.
• There should be a trailing newline (if use #define) (because you can't put the code right after the macro, you need a trailing newline).
• If there are multiple statements there should be if(1){...}else wrap or do{...}while(0) wrap.

Real world macros satisfy all three of them (except some nonstandard ones (never used in production code), for example the macro defined by

#define all(x) begin(x), end(x)

. With this you can do some (weird?) trick such as

sort(all(x))

, which avoid duplication of x in code - source: this or this)

---

Should that be enforced?

• Agree: That's the standard of C macro.
• Agree: That makes the macro more like a real "function".
• Disagree: That may change a lot of existing submissions.
• Disagree: Even without that condition, we can call it with variables, and wrap the return value in parentheses. This is "require more input than necessary".
• Disagree: That takes more bytes. (← should not be a problem)

Answer 1

As I see it this is quite simple: the default submission format is program or function, including function-like constructs. Since C has functions, a function-like construct in C should be interchangeable with a function, so if there are expressions where substituting a valid function with the given macro would change the behaviour, the macro is not a valid answer.

Answer 2

It must work

I can't say I'm even moderately versed in this "C macro passed directly to the compiler" concept, but in code golf the main requirement for an answer to be valid is just that it defines a function or program which solves the challenge. We very much do NOT care about best practices as long as your compiler or interpreter doesn't enforce them.

For example, in a comment you mention that the argument of the function should show up exactly once in the macro to avoid extra side effects that would cause different behavior compared to defining the function normally. Code golf doesn't care unless it causes problems for that exact challenge. Most of the time your inputs would be literal values with no side effects anyway. As long as the compiler doesn't complain and the "function" can be called and works, then it remains valid.

Taking your example, the macro code seems to define a function (or function-like construct) f(n). If I want to call the function on a value x inside a program, and then store the return value in a variable y, I would write y = f(x);. As long as the macro results in that line being valid and resulting in y correctly containing the same result as any other valid answer would, then whatever "code" was passed to the compiler to define that "function" is a valid answer itself.

One thing specifically though: I would probably NOT allow a function to be defined in a way that calling it requires y = (f(x)); instead. Those parentheses should be in the source code if they are needed for the function to work.