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

From: Spencer Baugh <[email-masked]>
Date: Sat, 08 May 2021 13:13:42 -0400

Eli Zaretskii <[email-masked]> writes:
>> From: Spencer Baugh <[email-masked]>
>> Cc: [email-masked]
>> 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.