[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55:

From: Paul Eggert
Subject: Re: Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch)
Date: Tue, 3 Sep 2019 23:05:00 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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.

Attachment: 0001-Avoid-macros-in-pdumper.c-when-it-s-easy.patch
Description: Text Data

Attachment: 0001-Prefer-functions-to-macros-in-buffer.h.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]