[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: Wed, 4 Sep 2019 09:56:11 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Eli Zaretskii wrote:

How portable is "INLINE"

Quite portable, as its portability issues were shaken out years ago. It's been used in Emacs since 2013, and it's designed for C99-and-later so future C compilers should support it well.

(and if it's portable enough, why do we use a jmacro for it)?

First, for convenience so that it's easier to follow the C rule that exactly one compilation unit must declare a function to be 'extern inline' if any compilation unit declares the function to be plain 'inline'. Second, for portability to C compilers that still do not support C99-style 'extern inline' (are these still significant? I don't offhand know).

I FWIW, personally find the issue of confusion about macro argument
evaluation to be a very weak one as justification to get rid of macros

There are other reasons to avoid macros. Aside from the performance issue I mentioned in my buffer.h patch, debugging Emacs can be easier when C macros are avoided. On the Ubuntu 18.04.3 platform where I'm typing this message, when I'm using GDB to debug /usr/bin/emacs I can print expressions involving functions or constants but not expressions involving macros; this is because Ubuntu builds /usr/bin/emacs with -g instead of -g3. So avoiding macros helps make it easier to debug Emacs in my situation, which is common on GNUish platforms.

Of course functions and constants cannot replace some C macros, such as INLINE. But many of Emacs's C macros ought to be functions or constants now, and this is not simply to avoid confusion.

reply via email to

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