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.bugs Subject: bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros Date: Sat, 08 May 2021 09:55:38 +0300 Message-ID: <83sg2xaf4l.fsf@gnu.org> References: <877dkbsj9d.fsf@catern.com> <20210506213346.9730-16-sbaugh@catern.com> <835yzudcvz.fsf@gnu.org> <87o8dmr96v.fsf@catern.com> <83tunebsiu.fsf@gnu.org> <87mtt6p6co.fsf@catern.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18058"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48264@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 08 08:57:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1lfGti-0004Zv-5V for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 May 2021 08:57:10 +0200 Original-Received: from localhost ([::1]:53582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lfGth-0000oO-4v for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 May 2021 02:57:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57674) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lfGsc-00080M-NM for bug-gnu-emacs@gnu.org; Sat, 08 May 2021 02:56:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36909) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lfGsc-0005Hr-01 for bug-gnu-emacs@gnu.org; Sat, 08 May 2021 02:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lfGsb-0000o3-Sh for bug-gnu-emacs@gnu.org; Sat, 08 May 2021 02:56:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 May 2021 06:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48264 X-GNU-PR-Package: emacs Original-Received: via spool by 48264-submit@debbugs.gnu.org id=B48264.16204569493093 (code B ref 48264); Sat, 08 May 2021 06:56:01 +0000 Original-Received: (at 48264) by debbugs.gnu.org; 8 May 2021 06:55:49 +0000 Original-Received: from localhost ([127.0.0.1]:48455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lfGsP-0000np-Be for submit@debbugs.gnu.org; Sat, 08 May 2021 02:55:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lfGsN-0000ni-Nl for 48264@debbugs.gnu.org; Sat, 08 May 2021 02:55:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53522) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lfGsI-00052h-AH; Sat, 08 May 2021 02:55:42 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4360 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 1lfGsH-0007E5-EF; Sat, 08 May 2021 02:55:42 -0400 In-Reply-To: <87mtt6p6co.fsf@catern.com> (message from Spencer Baugh on Fri, 07 May 2021 17:43:51 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:205986 Archived-At: > From: Spencer Baugh > Cc: 48264@debbugs.gnu.org > Date: Fri, 07 May 2021 17:43:51 -0400 > > > If the sole purpose is to be able to detect coding mistakes, then > > there are other possibilities to do that, if the compiler cannot help > > in a way that leaves the sources readable. > > Hopefully. Although, I'm not sure this approach is fundamentally > unreadable? The field names are already mangled with the trailing "_" > to stop direct access; this is just further mangling them. Yes, but it's much more than just the appended _. Consider also the case of some developer instructing a user to provide values of these fields in a GDB session: currently we need to tell the user to use just "p foo->bar_". With this change, we'd need to make the user type much more, and possibly also make sure Emacs is compiled with -g3 to have the macros available to the debugger. > >> No, this is purely just changing the name of the fields - it has no > >> impact on functionality, C code can still set the buffer-local > >> variables. > > > > Then I guess the _defaulted_ part is a misnomer? > > Possibly; by "defaulted" I intended to mean that the field is one which > has a default. But I freely acknowledge it's not a great name. So how about using _d_ of _def_instead? It's much shorter and expresses the purpose no worse than _defaulted_. > Keep in mind though, this name isn't exposed to the programmer > anywhere - it might as well be _ABCDEFGHI_, nothing will change > outside the definition of the BVAR_DEFAULTED_FIELD macro. See above: I'd prefer to get rid of the macro for this purpose. > > Failing that, maybe we should simply have a test to detect the > > mistakes? That wouldn't prevent bad code from being compiled, but it > > should reveal it soon enough, since tests are regularly run on hydra. > > A conditionally-compiled runtime check would be very easy to add - I'd > just change BVAR to something like: > > (eassert (EQ (buffer_defaults->field ## _)); (buf)->field ## _) > > Which would make sure that it's not used on anything with a default. > But of course that's substantially more annoying than a compile time > check... I'm not sure I understand why this is much more annoying, can you elaborate? We have similar assertions, conditioned on ENABLE_CHECKING, elsewhere in our macros, like XWINDOW etc, so why not here?