From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Thoughts on replacing macros with static inline functions Date: Tue, 15 Nov 2022 14:45:19 +0200 Message-ID: <83r0y4idy8.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22527"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Brent Pappas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 13:46:59 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ouvL8-0005cJ-Sn for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 13:46:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouvJY-0006kG-Qf; Tue, 15 Nov 2022 07:45:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouvJT-0006iy-0J for emacs-devel@gnu.org; Tue, 15 Nov 2022 07:45:15 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouvJQ-00027m-9H; Tue, 15 Nov 2022 07:45:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=T3MU5LaUKxPqch1hyAXd8xZs3wL9UfpFPbMnIRPHI+I=; b=iyI3SOHrhd8z 5K5823JRwvCvUEeaeZmp/XGxToJzxFZgBveX/fHhkb3kT+DPE5f8f0JkxFHxzLicA8TpJO46+uMei ZXjpHiFsi0sa2n6cto48BGs8LTiiyKi03RRjetZUqRRm/BBnshBqOKLyUDEaEDIFecAvQMDQWK9Jy HD6TDeE5CnWKGwd0ko9VAzMX4XoelVHe6XHbnpwHOcEY8mdPKlx0uoPqaFo9LcCeHmM++Sp03VI3q kSaEIPXAcq7Z0XgtnlY+MSNq624uZ1+gRhWzhWgS0PGGDcshwTOud5+7SdNPgFhSBlQpjZJVaTGFU INvf8Mz/ejJwsqXMqX5jTA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouvJI-0006Rx-HP; Tue, 15 Nov 2022 07:45:07 -0500 In-Reply-To: (message from Brent Pappas on Mon, 14 Nov 2022 18:05:15 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299846 Archived-At: > From: Brent Pappas > 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.