bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@catern.com>
> Cc: 48264@debbugs.gnu.org
> Date: Sat, 08 May 2021 09:35:31 -0400
> 
> > So how about using _d_ of _def_instead?  It's much shorter and
> > expresses the purpose no worse than _defaulted_.
> 
> Sure, that would work.
> 
> >> 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.
> 
> Sure, we could mostly get rid of it, although it's important that the
> argument to BVAR_OR_DEFAULT be "case_fold_search" rather than, say,
> "case_fold_search_def", even if the field is named the latter.
> Otherwise one might accidentally call BVAR with "case_fold_search_def",
> which would compile but behave wrong at runtime - and preventing that is
> the whole point of the different names.

I agree, but I'm not sure I see the connection.  Can you tell how
getting rid of the macro in the likes of b->SOME_MACRO(foo) could run
afoul of the argument to BVAR_OR_DEFAULT?

> >>   (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?
> 
> I mean that it's annoying that merely compiling doesn't detect the usage
> error, one has to actually run tests.

Well, with eassert just running Emacs will sooner or later crash with
SIGABRT, so I think it's acceptable.  Again, we do that in other
cases, quite a lot, actually, so there's no reason to treat this
particular case differently.

> If you think such a conditionally-compiled runtime check would be
> acceptable for applying these changes, I can go ahead and write that.

Yes, I think so.  But if Lars or Stefan think differently, I might
reconsider.