GNU bug report logs - #48264
28.0.50; Changing the default for DEFVAR_PER_BUFFER variables takes O(#buffers) time

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> catern.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 48264 <at> debbugs.gnu.org
Subject: bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros
Date: Sat, 08 May 2021 13:13:42 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> catern.com>
>> Cc: 48264 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.