Pip Cet wrote:

>>> - doubly-evaluated macro arguments (the one I can think of offhand is
>>> DUMP_SET_REFERRER, which is harmless, but others might not be)
>>
>> Do you mean evaluated as in macro expansion, or evaluated as in execution at
>> runtime? If the latter, I don't get the problem there. Many other macros assume
>> that arguments are side effect free, and some of these cannot be turned into
>> inline functions easily.
> 
> I think it's likely we still have some places that assume their
> arguments are side-effect-free, but whose callers pass arguments with
> side effects.

The DUMP_SET_REFERRER macro was indeed confusing. But weren't you talking about 
how that macro evaluates its OBJECT arg either zero or one time, vs evaluating 
arguments more than once? Anyway, it's not that hard to adjust the code so that 
it can be defined as a function rather than a macro, so I did that and installed 
the attached first patch.

More generally, I share your concern about confusion about how many times a C 
macro argument is evaluated. The Emacs C source has a lot of macros, though. 
Rather than continue to audit all uses of all macros, I've found it more 
effective to replace many/most of these macros with functions, so that we don't 
have to worry about evaluation. Similarly for object-like macros and constants. 
See, for example, the attached second patch, which I just installed (I was 
partly inspired by your email). This sort of improvement gives us fewer macro 
calls to audit. And as a side effect it typically improves Emacs performance 
when optimized (though Emacs can get slower if optimization is disabled).

We can't easily remove all C macros from the Emacs source code, but when it's 
relatively easy (as is the case here) it's worth doing. I did this sort of thing 
to lisp.h in 2013 and that worked out reasonably well, and if someone gets the 
time it would be good to do it to other parts of the Emacs source code.