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

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@catern.com>
>> Cc: 48264@debbugs.gnu.org
>> Date: Sat, 08 May 2021 09:35:31 -0400
>> >> 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?

Just wanted to make sure we were on the same page.  I don't think
getting rid of the macro in b->SOME_MACRO(foo) will run afoul of the
argument to BVAR_OR_DEFAULT.