bug#48264: [PATCH v3 07/15] Add BVAR_OR_DEFAULT macro as a stub

[Spencer Baugh <sbaugh@catern.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@catern.com>
>> Date: Thu,  6 May 2021 17:33:38 -0400
>> Cc: Spencer Baugh <sbaugh@catern.com>
>> 
>> For buffer variables without a default, we still use BVAR.  For any
>> buffer variable with a default, we use BVAR_OR_DEFAULT.  A later
>> commit will statically enforce this.
>
> This part says they are the same:
>
>> --- a/src/buffer.h
>> +++ b/src/buffer.h
>> @@ -284,6 +284,8 @@ struct buffer_text
>>  
>>  #define BVAR(buf, field) ((buf)->field ## _)
>>  
>> +#define BVAR_OR_DEFAULT(buf, field) BVAR (buf, field)
>
> What am I missing here?

The commit message is accurate - we indeed use BVAR for buffer variables
without a default, and BVAR_OR_DEFAULT for buffer variables with a
default.

It's just that in this commit, those two behave identically.  The
immediate next commit makes them different.

I split it up in this way because this commit is the result of a big
tree-wide sed, no actual meaningful change; I think it's much easier to
understand the next commit when the two are kept separate.

> Also, I have a question: suppose we have a variable that is defined
> with DEFVAR_LISP, and then some Lisp calls make-variable-buffer-local:
> how will that work with these two macros when the C code needs to
> access the buffer-local value?

Nothing in these changes affect variables that are made into
buffer-locals from Lisp code; these changes only affect variables
built-in to Emacs that were defined with DEFVAR_PER_BUFFER.  So that
will just work the same as it does today - accesses to such variables
don't go through BVAR today.