Thoughts on replacing macros with static inline functions

Thoughts on replacing macros with static inline functions

[Brent Pappas]

Title: Thoughts on replacing macros with static inline functions

Hi,

I noticed that Emacs code sometimes uses macros where a static inline function
would appear to work equally as well.
For instance, consider the macro PAD defined in src/xsettings.c

#define PAD(nr)    (((nr) + 3) & ~3)

I imagine this could be turned into a function like so:

static inline int PAD(int nr)    { return (((nr) + 3) & ~3); }

The reason why one would want to replace macros with functions is because
functions are often easier to reason about than macros.
The GNU C Preprocessor manual even has a list of pitfalls one can fall into
when programming with macros.
So it may be worthwhile to turn such macros into functions to prevent
developers from accidentally falling into one of these pitfalls.

How interested would the Emacs community be in porting macros to functions?

Re: Thoughts on replacing macros with static inline functions

[Eli Zaretskii]

> From: Brent Pappas <pappasbrent@Knights.ucf.edu>
> Date: Mon, 14 Nov 2022 18:05:15 +0000
> msip_labels: 
> 
> I noticed that Emacs code sometimes uses macros where a static inline function
> would appear to work equally as well.
> For instance, consider the macro PAD defined in src/xsettings.c
> 
> #define PAD(nr)    (((nr) + 3) & ~3)
> 
> I imagine this could be turned into a function like so:
> 
> static inline int PAD(int nr)    { return (((nr) + 3) & ~3); }

This is only equivalent in an optimized build, where modern compilers
usually inline such functions.  Emacs developers (yours truly
included) frequently run unoptimized builds because optimized code can
be tricky to debug.  Using functions in an unoptimized build can slow
down Emacs, especially if the macro you want to replace is used in
inner loops that are "hot spots" in Emacs.

> The reason why one would want to replace macros with functions is because
> functions are often easier to reason about than macros.
> The GNU C Preprocessor manual even has a list of pitfalls one can fall into
> when programming with macros.
> So it may be worthwhile to turn such macros into functions to prevent
> developers from accidentally falling into one of these pitfalls.
> 
> How interested would the Emacs community be in porting macros to functions?

I'd prefer not to do this en masse.  Certain specific cases could be
considered on a case by case basis.  But even here, changes like this
tend to make the code less familiar for people who have many years of
hacking Emacs under their belts, so the reason for the conversion
would have to be very convincing for me to agree.

Thanks.

Re: Thoughts on replacing macros with static inline functions

[Po Lu]

Brent Pappas <pappasbrent@Knights.ucf.edu> writes:

> Title: Thoughts on replacing macros with static inline functions
>
> Hi,
>
> I noticed that Emacs code sometimes uses macros where a static inline function
> would appear to work equally as well.
> For instance, consider the macro PAD defined in src/xsettings.c
>
> #define PAD(nr)    (((nr) + 3) & ~3)
>
> I imagine this could be turned into a function like so:
>
> static inline int PAD(int nr)    { return (((nr) + 3) & ~3); }

I find that rather ugly.  PAD is an example of an extremely trivial
expression that should really be a macro.

> How interested would the Emacs community be in porting macros to functions?

Not very, in this case.  That exact PAD macro is not only an idiom used
throughout the Emacs X11 code, it is more-or-less an idiom of the entire
X Window System, copied around and used extensively throughout the X
sample server, Xlib, and C-language clients.

In addition, we try to avoid undue changes to working code, so giving
carte blanche to change macros to static functions is not something we
really want to do.  But if you want to do that to a few big, ugly,
macros around an area in which you are making actual changes, please go
ahead.

Re: Thoughts on replacing macros with static inline functions

[Stefan Monnier]

> How interested would the Emacs community be in porting macros to functions?

Most of the macros are there for historical reasons.
We do change macros to functions, for all the reasons you mention.
But we prefer to do it little by little as we touch the
corresponding code.


        Sefan

Re: Thoughts on replacing macros with static inline functions

[xenodasein--- via Emacs development discussions.]

Nov 15, 2022, 13:49 by luangruo@yahoo.com:

> Brent Pappas <pappasbrent@Knights.ucf.edu> writes:
>
>> Title: Thoughts on replacing macros with static inline functions
>> ...
>>
>>
> I find that rather ugly.  PAD is an example of an extremely trivial
> expression that should really be a macro.
>
>> How interested would the Emacs community be in porting macros to functions?
>>
>
> Not very, in this case.  That exact PAD macro is not only an idiom used
> throughout the Emacs X11 code, it is more-or-less an idiom of the entire
> X Window System, copied around and used extensively throughout the X
> sample server, Xlib, and C-language clients.
>
> In addition, we try to avoid undue changes to working code, so giving
> carte blanche to change macros to static functions is not something we
> really want to do.  But if you want to do that to a few big, ugly,
> macros around an area in which you are making actual changes, please go
> ahead.
>

You answer in a tone that means you speak for everyone else, is this
intentional if so why?

Re: Thoughts on replacing macros with static inline functions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I agree -- there is nothing wrong with macros, and we should
not make it or goal to eliminate the use of macros.
Macros have pitfalls, which are consequences of their basic nature,
but we know how to avoid them, and have documented the methods.

The GNU C Language Introduction and Reference Manual advises users on
how to deal with these and many other pitfalls of the C language.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Thoughts on replacing macros with static inline functions

[xenodasein--- via Emacs development discussions.]

Nov 18, 2022, 05:05 by rms@gnu.org:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I agree -- there is nothing wrong with macros, and we should
> not make it or goal to eliminate the use of macros.
> Macros have pitfalls, which are consequences of their basic nature,
> but we know how to avoid them, and have documented the methods.
>
> The GNU C Language Introduction and Reference Manual advises users on
> how to deal with these and many other pitfalls of the C language.
>
> -- 
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (> https://internethalloffame.org> )
>

Why do you not consider __attribute__((always_inline)) an improvement
over macros where applicable?

Re: Thoughts on replacing macros with static inline functions

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Why do you not consider __attribute__((always_inline)) an improvement
> over macros where applicable?

And exactly where is __attribute__((always_inline)) present?  Only on
GCC, right?  What about Sun C, and other C99 compilers?

And how is an additional function an improvement over extremely trivial
macros, like these:

#define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
#define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
#define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)

?

Re: Thoughts on replacing macros with static inline functions

[xenodasein--- via Emacs development discussions.]

Nov 18, 2022, 06:27 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Why do you not consider __attribute__((always_inline)) an improvement
>> over macros where applicable?
>>
>
> And exactly where is __attribute__((always_inline)) present?  Only on
> GCC, right?  What about Sun C, and other C99 compilers?
>
> And how is an additional function an improvement over extremely trivial
> macros, like these:
>
> #define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
> #define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
> #define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)
>
> ?
>

Lookup why functions are considered an improvement over macros.

As for compiler support, I bet the time spent debugging where there is
support is going to dwarf where isn't, so trade-off is clear.

Re: Thoughts on replacing macros with static inline functions

[tomas]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

On Fri, Nov 18, 2022 at 07:19:45AM +0100, xenodasein--- via Emacs development discussions. wrote:

[...]

> Why do you not consider __attribute__((always_inline)) an improvement
> over macros where applicable?

I think you spelled it yourself: "where applicable": this is
something which has to be considered on a case by case basis.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Thoughts on replacing macros with static inline functions

[xenodasein--- via Emacs development discussions.]

Nov 18, 2022, 06:59 by tomas@tuxteam.de:

> On Fri, Nov 18, 2022 at 07:19:45AM +0100, xenodasein--- via Emacs development discussions. wrote:
>
> [...]
>
>> Why do you not consider __attribute__((always_inline)) an improvement
>> over macros where applicable?
>>
>
> I think you spelled it yourself: "where applicable": this is
> something which has to be considered on a case by case basis.
>
> Cheers
> -- 
> t
>

For you and me sure, I was curious about Richard's opinion.

Re: Thoughts on replacing macros with static inline functions

[Po Lu]

xenodasein@tutanota.de writes:

> Lookup why functions are considered an improvement over macros.

I don't.

> As for compiler support, I bet the time spent debugging where there is
> support is going to dwarf where isn't, so trade-off is clear.

You mean, trading debugging time for runtime? That tradeoff was already
made the moment Emacs was written in C, and besides, modern debuginfo
formats already support macros.

Re: Thoughts on replacing macros with static inline functions

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Richard Stallman <rms@gnu.org>,  xenodasein@tutanota.de,  Eli Zaretskii
>  <eliz@gnu.org>,  pappasbrent@knights.ucf.edu
> Date: Fri, 18 Nov 2022 14:27:09 +0800
> 
> And how is an additional function an improvement over extremely trivial
> macros, like these:
> 
> #define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
> #define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
> #define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)

The purpose of macros such as the above is to explain the meaning of
the code in human-readable terms.  Replacing this by functions makes
no more sense than replacing "c = a + b;" with a function.

Re: Thoughts on replacing macros with static inline functions

[xenodasein--- via Emacs development discussions.]

Nov 18, 2022, 08:34 by eliz@gnu.org:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Richard Stallman <rms@gnu.org>,  xenodasein@tutanota.de,  Eli Zaretskii
>>  <eliz@gnu.org>,  pappasbrent@knights.ucf.edu
>> Date: Fri, 18 Nov 2022 14:27:09 +0800
>>
>> And how is an additional function an improvement over extremely trivial
>> macros, like these:
>>
>> #define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
>> #define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
>> #define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)
>>
>
> The purpose of macros such as the above is to explain the meaning of
> the code in human-readable terms.  Replacing this by functions makes
> no more sense than replacing "c = a + b;" with a function.
>

Right?  Who needs a proper API when you can have paranoid parentheses
macros with bit hackery!

Re: Thoughts on replacing macros with static inline functions

[Po Lu]

xenodasein@tutanota.de writes:

> Right?  Who needs a proper API when you can have paranoid parentheses
> macros with bit hackery!

And why would there be an API, much less a ``proper'' one, to extract
status flags from a Motif drag-and-drop message (a single CARD32?)

Re: Thoughts on replacing macros with static inline functions

[Eli Zaretskii]

> Date: Fri, 18 Nov 2022 12:31:59 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org, rms@gnu.org,
> 	pappasbrent@knights.ucf.edu
> 
> Nov 18, 2022, 08:34 by eliz@gnu.org:
> 
> >> #define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
> >> #define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
> >> #define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)
> >>
> >
> > The purpose of macros such as the above is to explain the meaning of
> > the code in human-readable terms.  Replacing this by functions makes
> > no more sense than replacing "c = a + b;" with a function.
> >
> 
> Right?  Who needs a proper API when you can have paranoid parentheses
> macros with bit hackery!

Bitwise operations are first-class citizens in C code, so your sarcasm
is misguided.

Re: Thoughts on replacing macros with static inline functions

[Stefan Monnier]

> Why do you not consider __attribute__((always_inline)) an improvement
> over macros where applicable?

Can we drop this discussion.  AFAIK all those who matter already
explained clearly that we generally agree it's an improvement, but that
it's not enough of an improvement to justify making the change just for
the sake of it.

IOW we all agree on the general idea, we just disagree on the degrees
and I see no way we'll convince each other to agree on what degree
is right.  So we just have to tolerate other people's preferences, with
the understanding that none of us is *right*.


        Stefan

Re: Thoughts on replacing macros with static inline functions

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Why do you not consider __attribute__((always_inline)) an improvement
>> over macros where applicable?
>
> Can we drop this discussion.  AFAIK all those who matter already
> explained clearly that we generally agree it's an improvement, but that
> it's not enough of an improvement to justify making the change just for
> the sake of it.

Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1121 bytes --]